From around the globe, it's theCUBE, presenting Accelerating Automation with DevNet, brought to you by Cisco. Hey, welcome back everybody. Jeff Frick here with theCUBE, coming to you from our Palo Alto studio with ongoing coverage of the Cisco DevNet event it's called Accelerating Automation with DevNet in the new normal. And we certainly know the new normal is not going away but we've been doing this in the middle of March or all the way to October. And so we're excited to have our next guest. He's Thomas Shivey. He's the vice president of product marketing and data center networking for the intent-based networking group at Cisco. Thomas, great to see you. Hey, good to see you too. Yeah. Yeah, and truly we're in a new normal as everybody can see in our background. Exactly, exactly. So Bob, I mean, I'm curious, we've talked to a lot of people, we talked to a lot of leaders, you know, especially like back in March and April with this light switch moment, which was, you know, no time to prep and suddenly everybody has to work from home, teachers got to teach from home. And so you got the kids home, you got the spouse home, everybody's home trying to get on the network and do their Zoom calls and their classes. I'm curious from your perspective, you guys are right there on the network, you're right in the infrastructure. What did you hear and see kind of from your customers when suddenly, you know, March 16th hit and everybody had to go home? Well, good point. A, I do think we all appreciate the network much more than we used to do before. And then the only other difference is I'm really more on Rebix calls and Zoom calls, but, you know, otherwise, yes. What I do see actually is that, as I said, network becomes much more obvious as a critical piece. And so before we really talked a lot about agility and flexibility, these days we talk much more about resiliency, quite frankly. And what do I need to have in place with respect to network to get my things from left to right and, you know, most to south and east to west, as we say in the data center. And that just is for most of my customers a very, very important topic at this point. Right.  I'm sure there was some excitement and some kudos in terms of, you know, it is all based on the network and it is kind of this quiet thing in the background that nobody pays attention to. It's like a ref in the football game until they make a bad play. So, you know, it is pretty fascinating that you and your colleagues have put this infrastructure in that enabled us to really make that move with really no prep, no planning and actually have a whole lot of services delivered into our homes that we're used to getting at the office or used to getting at school. Yeah.  We're clearly talking about some of these trends and the way I look at this, trends as being distributed data centers and having the ability to move your workloads and access for users to wherever you want to be. And so I think that clearly went on for a while. And so in a sense, we preppers are not what we're prepping for. But as I said, resiliency just became so much more important. And, you know, one of the things I actually do, a little prep before a block I put out in the August around resiliency, if you didn't put this in place, you better put it in place because I think as we all know, we started in March, this is like maybe two or three months. We're now in October. And I think this is the new normal for some time being. Yeah, I think so. So let's stick on that theme in terms of trends, right? The other great trend is public cloud and hybrid cloud and multi-cloud. There's all types of variants on that theme. You had in that blog post about resiliency in data center cloud networking, data center cloud. You know, some people think, wait, it's kind of an either or, I either got my data center or I've got my stuff in the cloud and I've got public cloud. And then as I said, hybrid cloud, you're talking really specifically about enabling both inner data center resiliency within multi data centers within the same enterprise as well as connecting to the cloud. That's probably counterintuitive for some people to think that that's something that Cisco is excited about and supporting. So I wonder if you can share, you know, kind of how the market is changing, how you guys are reacting and really putting the things in place to deliver customer choice. Yeah, no, it's actually to me, it's really not counterintuitive because in the end, what I'm focusing on and the company's focusing on is what our customers want to do and need to do. And that's really what, you know, most people call hybrid cloud or multi cloud. In the end, what it is, is really the ability to have the flexibility to move your workloads where you want them to be. And there are different reasons where you want to place them, right? You might have placed them for security reasons, you might have placed them for compliance reasons, depending on which customer segment you're after, if you're in the United States or in Europe or in Asia, there are a lot of different reasons where you're going to put your sinks. And so I think in the end, what an enterprise looks for is that agility, flexibility and resiliency. And so really what you want to put in place is what we call like a cloud on RAM, right? You need to have an ability to move sinks as needed. But the larger context action, which we see in the last couple of months, accelerating is really this whole theme around digital transformation, which goes hand in hand then with the requirement on the IT side really do an IT operations transformation, right? How IT operates. And I think that's really exciting to see and this is actually where a lot of my discussions I was customers, what does it actually mean with respect to the IT organization? And what are the operational changes is a lot of our customers are going through, quite frankly, accelerated going through. Right, and automation is in the title of the event. So automation is an increasingly important thing as we know and we hear all the time, the flows of data, the complexity of the data, either on the security or the way the network's moving or as you said, shifting workloads around based on dynamic situations, whether that's business security, et cetera. And to suffer to find networkings been around for a while, how are you seeing kind of this evolution in adding more automation to more and more processes to free up those kind of limited resources in terms of really skilled people to focus on the things that they should be focusing on and not stuff that hopefully you can get a machine to run with some level of automation. Yeah, yeah, that's a good point. And it's the tech line I have, sometimes when my mind is really going from cloud ready, which I think most of our infrastructure is today to cloud native. And so let me a little expand on this, right? It's like the cloud ready is basically what we have put in place over the last five to six years. All the infrastructure that our customers have and network infrastructure, all the Nexus 9000, they're all cloud ready, right? And what this really means, you have APIs everywhere, right? Whether this is on the box, whether it's on the controller, whether this is on the operations tools, all of these are API enabled. And that's just a foundation for automation, right? You have to have that. Now, the next step really is what do you do with that capability, right? And this is the integration with a lot of automation tools. And there's the whole range, right? This is where the IT operation transformation kicks in different customers at different speed, right? Some just, you know, I use these APIs and use normal tools that they have in the network world just to pull information. Some customers go for inferencing. I want to integrate this with some CFDB tools. Some go even further than saying, this is like the cloud native piece of thing. Oh, I want to use, let's say Red Hat Ansible. I want to use HashiCorp, Terraform and use those things to actually drive how I manage my infrastructure. And so that's really the combination of the automation capability plus the integration with relevant cloud native enabling tools that really is happening at this point. We're seeing customers accelerating that motion, which really then drives us how they run their IT operations. And so that's a pretty exciting area to see. Given, as I said, we have the infrastructure in place. There's no need for customers to actually do change something. Most of them have already the infrastructure that can do this. It's just not doing the operation change, the process changes to actually get there. Right, and it's funny, we recently covered pager duty and they highlight, which you just talked about the cloud native, which is all of these applications now are so interdependent on all these different APIs, pulling data from all these different applications. So, A, when they work great, it's terrific. But if there's a problem, there's a whole lot of potential throats to choke out there and find those issues. And it's all being connected via the network. So, it's even more critically important not only for the application, but for all these little tiny components within the application to deliver ultimately a customer experience within very small units of time so that you don't lose that customer. You complete that transaction, they check out their shopping cart, all these things that are now created with cloud native applications that just couldn't really do before. No, you're absolutely right. And this is like, yes, I said, I'm actually very excited because it opens up a lot of abilities for our customers how they want to actually structure the operation, right? One of the nice things around this all, automation plus tool integration, cloud native tool integration is, you actually open this up and out as whole automation train, not just to the network operations person, right? You also open it up and can use this for the SecOps person or for the DevOps person or for the cloud ops engineering team, right? Because the way it's structured, the way we built this is literally as an API interface and you can now decide what is your process? Do you want to have a more traditional process? You have a request, network operation teams executes the request using these tools and then hands it back over. Or you say, hey, maybe some of these security things I got to hand over the SecOps team and they can directly call these APIs, right? Or even one step further, you can have the opportunity that the DevOps or the application team actually says, hey, I got to write a whole infrastructure as code kind of a script or template and I just execute, right? And it's really just using what the infrastructure provides. And so that whole range of different user roles in our customer base, what they can do with the automation capability that's available is just very, very exciting, right? Because it's really unleashes a lot of flexibility how they want to structure and how they want to rebuild the IT operations processes. That's interesting because the DevOps culture has taken over a lot, right? Obviously changed software programming for the last 20 years and I think there's a lot of just kind of the concept of DevOps versus necessarily the actual things that you do to execute that technique. And I don't think most people would think of network ops or net ops, whatever the equivalent is in the networking world to have kind of a fast changing dynamic kind of point of view versus a, you know, stick it in, you know, spec it, stick it in, lock it down. So I wonder if you can, you can share how, you know, kind of that DevOps attitude, point of view workflow, whatever the right verb is has impacted, you know, things at Cisco and the way you guys think about networking and flexibility within the networking world. Yeah, literally, absolutely. And again, it's all customer driven, right? There's none of this, none of this is really, actually, you know, a little bit of credit, maybe some of us where we have a vision, but a lot of this is just customer driven feedback. And yeah, we do have even network operations teams come to be saying, hey, we use Ansible heavily on the compute site. We might use this for seven, we want to use the same for networking. And so we made available all these integrations with the variety as a state, whether these are the switches, whether it's our ACI and DCNM controller or our multi-site orchestration capabilities. All of these has Ansible integration available, right? The other one, as I mentioned, Hashi from Terraform, we have integrations available. And you see the request for these tools to use that. And so that is the motion we're in for over a year now and another block actually that's out there, we just posted saying, you'll all set what you can do. And then in parallel to this, right, just making the integration available, we also have a very, very heavy focus on, definite and enablement and training. And a little plug, and I know, probably part of the segment, the whole definite community that Cisco has is very, very vibrant. And the beauty of this is, right, if you look at this, whether you're a net-ups person or a deaf-ups person or a sec-ups person, it doesn't really matter. There is a lot of like capability available to just help you get going or go from one level to the next level, right? And there's simple things like sandbox environments where you can, you know, without stress, try things out, snippets of code are there, you can do all of these things. And so we do see, it's a kind of a push and pull, a tremendous amount of interest and a tremendous time people spend to learn, quite frankly, and that's another side product of, you know, the situation we're in, people sit home and say, okay, online learning is the thing. So these tools are used very, very heavily. Right, right. That's awesome, because, you know, we've had Susie Wee on a number of times and I know she and Mandy and the team, right, really built this DevNet thing and it really follows along this other theme that we see consistently across other pieces of tech, which is democratization, right? Democratization of the access tool, taking it out of just a mahogany row with, again, a really limited number of people that know how to make it work and can make the changes and then opening it up to a software-defined world where now, you know, it's this application-centric point of view where the people that are building the apps to go create competitive advantage now don't have to wait for, you know, the one network person to help them out and put up these environments. Really interesting. And I wonder, you know, when you look at what's happened with Public Cloud and how they kind of change the buying parameter, how they kind of change the degree of difficulty to get projects started, you know, how you guys have kind of integrated that type of thought process to make it easier for app developers to get their job done? Yeah, I mean, again, it's, I typically look at this more from a customer lens, right? It's the transformation process. And it always starts as I want agility, I want flexibility and I want resiliency, right? This is where we talk to a business owner what they're looking for. And then that translates into an ITO operations process, right? Your strategy needs to map them, how you actually do this. And that just tries then, what tools do you want to have available to actually enable this, right? And the enablement, again, is for different roles, right? There is, you need to give sync services to the app developer and the platform team and the security team, right? To your point, so the network can act at the same speed. But you also give tools to the network operations teams because they need to adjust and we have the ability to react to some of these requirements, right? And it's not just automation. I think we focused on that, but there's also to your point, the need, how do I extend between data centers, you know, just for backup and recovery? And how do I extend into public clouds, right? And in the end, that's a network connectivity problem. And we have softness, we have made this available, we have integrations into AWS, we have integrations into Azure to actually make this very, very easy from a network perspective to extend your private domains, private networks into virtual private networks on these public clouds. So from an app developer perspective, now it looks like he's on the same network. It's a protective enterprise network. Some of it might sit here, some of it might sit here, but it's really looking the same. And that's really in the end, I think what a business looks at, right? They don't necessarily want to say I need to have something separate for this deployment or separate for that deployment. What they want is I need to deploy something. I need to do this resilient. In a resilient way, in an Android way, give me the tools. And so that's really where we focus and what we're driving, right? It's that combination of automation consistently and then DevNet tools available that we support, but they're all open. They're all standard tools as the ones I mentioned, right? That everybody's using. So you're not getting into this, oh, this is specific to Cisco. It's really democratization. I actually like your term. Yeah, it's a great term and it's really interesting, especially with the APIs and the way everything is so tied together that everyone kind of has to enable this because that's what the customer is demanding. And it is all about the applications and the workloads and where those things are moving, but they don't really want to manage that. They just want to deliver business benefit to their customers and respond to competitive threats in the marketplace, et cetera. So it's really an interesting time for the infrastructure to really support kind of this at first point of view versus the other way around is kind of what it used to be and enable this hyper fast development, hyper fast change in the competitive landscape or else you will be left behind. So super important stuff. Yeah, no, I totally agree. And as I said, I mean, it's kind of interesting is we started on the Cisco data center side. We started as probably six or seven years ago when we named that application centric. Clearly a lot of these concepts evolved, but in a sense it is that reversal of the role from the network provides something and you use to this is what I want to do and I need a service thinking on the networking side to expose service that can be consumed.  They have all the capabilities there. They can literally take advantage. There's really nothing that stops them at this point. Well, it's good times for you because I'm sure you've seen all the memes in social media, right? What's driving your digital transformation? Is it the CEO, the CMO or COVID? And we all know the answer to the question. So I don't think the pace of change is going to slow down anytime soon. So thanks for keeping the network up and enabling us all to get done what we have to get done and all the little magic that happens behind the scenes. Yeah, no, thanks for having me. And again, yeah, if you're listening and you're wondering how do I get started? Cisco definitely that's the place to go. It's fantastic, fantastic environment and I highly recommend everybody roll up your sleeve and the best reasons you can have. Yeah, and we know once the physical events come back we've been to DevNet create a bunch of times and it's a super vibrant, super excited, super really engaged community, sharing lots of information. It's still kind of that early vibe where everyone is still really enthusiastic and really about learning and sharing information. So, like I say, Susan and the team have really built a great thing and we're happy to continue to cover it and eventually we'll be back face to face. Okay, look forward to that as well. All right, thanks. He's Thomas, I'm Jeff. You're watching Continuing Coverage of Cisco DevNet Accelerating with Automation and Programmability. Thanks for watching. We'll see you next time.


Everybody we're back, this is Dave Vellante, I'm with Wikibon.org, this is theCUBE, Silicon Angles flagship product, I'm here with Jeff Frick, my co-host for the week. Our colleagues, John Furrier, David Floyer, and Jeff Kelly are down at Sapphire now. Our other colleagues, Kenny, who was here earlier and Mark Risen Hopkins, are at Google I.O., so we're getting reports from the field at Google I.O. It's a big week. It's a big theCUBE. It's a big week here. It's a busy week for theCUBE. It's not Hell Week quite yet, that's coming in June, we love it, and we really appreciate the tweets, I'm at Dave Vellante. He is at Jeff Frick, so you can tweet us, we can get your questions on it. We're here at Knowledge, ServiceNow's big customer event, and we are double clicking on the practitioners. I'm very impressed, Jeff, with the enthusiasm with which IT practitioners come on our show and the degree to which there's alignment between what ServiceNow is telling us and their marketing messages and what the customers are actually doing with the product. Neil Laffenberg is here. He's the Senior Manager of IT Service Management at FICO. Neil, thanks for coming on theCUBE and sharing your story. Thanks for having me. Yeah, so you heard my little intro and it's been consistent. We're seeing this pattern emerge. Happy customers, transforming IT, going from no to now, is that your story? It really is. The one thing I've been telling everybody all week is the thing I love most about the ServiceNow platform is I no longer have to tell people I can't do something. And I know that's right up the line with their marketing material, so I feel kind of cheesy saying it. But I no longer have to say now, now I have to say, when can we do it? Is this the right way to do it? Can we afford to do it? But I know that I can do it. Right, so tell us more about FICO. Let's actually start there and move into it. Sure, FICO is a company. We're a located, our IT organization at least is located in the Midwest, but where our corporate offices are out in San Jose. We're primarily known for our financial services work, our credit scoring is what most people know us for, MyFICO.com, if you originate alone in the US, you're most likely gonna have our scores used to vet you. But at our core, we're a software design and analytics company. So we design software for fraud detection, asset recovery actions, decision making, retail, the best next decisions, that kind of stuff. So you're in the data business. We are in the data business, absolutely. So tell us what are the big things that are driving that business? I mean, obviously you've got data growth, you've got tons of data, other sources, you've got the financial crisis, which sort of weighed heavily on your industry. Absolutely. You've got technology, sort of big data and cloud mashing together, all kinds of really. It's an exciting time. It is, it is. And we're facing all the same challenges that everybody else has big data. Big data, everybody's trying to figure out what that means and how we do that and how we deal with it. But I think the biggest thing we're seeing right now is there's a major push in the industry for trying to figure out what platform and as a service really means. Because we've got a number of vendors that we're working with internally that all are doing platform in their own kind of way. ServiceNow being one of them. ServiceNow's platform is a service as it pertains to having a framework that you can develop workflow based applications on. Let's summarize it that way. But there's other vendors out there who are doing a version of it with infrastructure as a service that's more subscriptive where you say I need this kind of a MySQL server or I need a web server. And then you have others that have like a middleware stack around software development. So platform as a service is this, I think it's the next cloud personally. It's where everybody's trying to figure out what it means but it's kind of the next thing that everybody wants to get to. We were talking to earlier at the start of the show today. We were talking about how these distinct clouds, infrastructure as a service, platform as a service, software as a service, they're starting to blend together. Absolutely. You see things like the Pivotal Initiative come out. Yep. Everybody wants to be the next big data platform. You're seeing service now as sort of a version of platform as a service. They do. It's not as intense as, let's say, maybe a Heroku or a Python. No. In the development environment, I can use Java, but it's really the thrusters, business users, app creator, things like that. So these lines are blurring. It's interesting to hear you as a practitioner talk about that. So how do you see that all shaped? First of all, if I understand it correctly, you would consider service now, not just a SaaS, but also a platform as a service. Increasingly, that's their future. I personally do. And I think it's interesting. The platform as a service model we're seeing is really, it's almost aligned against three verticals. You have the one that service now fits into, which is more around providing you a platform to develop things to make your job easier or to make your company more productive and a workflow, ticketing, tracking, approval, emailing, reporting kind of sense. There's another one that's kind of, how do we take these diverse infrastructures and provision them more quickly at the level above the actual platform? Because nobody really cares about the platform. You've been seeing it all week. It's around, it's going to become a commodity. It's that next level that everybody's trying to figure out. How do we be dynamic there? And then the other piece is the software development piece coming up with a middleware stack that sits, or sorry, a stack that sits on top of your core things that run your app and making application design easier. So I kind of think about it as three separate columns that everybody's kind of going against and bleeding into. Yeah, and then we, so we were at the AWS summit and clearly big developer community there. Jeff, I wasn't there, but Jeff and John Furrier were at the OpenStack summit. Huge push for developers. We're talking to them as well. I mentioned the whole pivotal initiative. You've got Paul Moritz now running, essentially trying to attract developers. You've got Cloudera, you've got Hortonworks, you've got all of these trends emerging and it's, as I say, it's a very exciting time. And then there's ServiceNow. So it strikes me, so we all know that if Microsoft, Azure is throwing those guys Google, I mean everybody, you know, he who owns the developer is going to, you know, make a lot of money and build a big ecosystem. But ServiceNow seems to have a different philosophy. Yes, they want to attract, they can track developers, like to say Java, JavaScript or whatever, but it's more the business user and those people that may not be hardcore programmers. Absolutely, and it's true. I mean we, my team and myself even, I'm in the tool day to day and I don't consider myself a developer by any means, but we can all, everybody on the team, look at a chunk of JavaScript and understand what it does and probably make some modifications to it. And we were able to start doing that very, very quickly. Our implementation, we went and started our implementation October 1st of last year and that we did a week of discovery and we went live on December 4th. And that was what the core platform, incident change, problem config, and a good number of customizations that we needed for our business, enterprise monitoring, LDAP integration, inbound email and a few other things. So we were able to very rapidly move from our previous platform to ServiceNow and gain all of the future direction that ServiceNow gives us. In fact, since then we've gone live with our project initiation, which is some people call that demand management. We've gone live with project management. We've gone live with our initial service catalog and we're starting asset management right now and that's since October 1st start. By the way, I'd love that you call the project initiation as opposed to demand management. I've always hated the term demand management. I know. I was like, okay, you have demand. Demand's a good thing. Yeah, that's where innovation occurs. We kind of split our demand, right? So the project piece is one thing, everything else we turn into catalog items, just separate that realm out.  What was the catalyst to bring in ServiceNow? The biggest catalyst for us really was we needed to get out of the business of running a tool and we needed to get into the business of providing value to the business. So we spent so much of our time just keeping our previous platform running that we were never able to make serious time investments to make it better, to make the business better. And now I purchase ServiceNow and I have all these things that I can do that I don't have to pay anything extra for or I don't have to put an extra platform out there or an extra environment or it just, it lends itself very well to dynamic growth, small successful forward steps. I like that you're talking about value. I think there actually needs to be more of a discussion of IT value. You actually don't hear a lot of that from ServiceNow and I think it's an opportunity for them. I see ServiceNow as a platform to be able to scale the business and deliver IT value, actually track the value flow that IT is bringing to the organization so that the organization can exploit IT in new ways. Are you seeing that within Europe? We are, I mean we've already started to reach out into other things which I mean, are outside of IT or adjacent to IT and bring them into the fold and make it a better organization in the whole. We're integrating better with finance, we're integrating better with accounting, we're integrating better with HR and facilities. Everybody kind of wants in on this thing and it's not just IT, yes, IT is the core, but we've really been able to reach out into other areas where people need this kind of help. They need workflow help, they need approval help, they need small application help. It's a great platform for that, really is. What were your concerns prior to bringing in ServiceNow about ServiceNow about the platform? I think the general concerns that a lot of people have around data security, if there ever was a need to leave the platform what would that be like? That's always a concern, can I take my data with me? But we, the community in our area, the Twin Cities area is really, really strong around ServiceNow and we had a lot of people that kind of gave us their experiences and gave us a lot of feedback so we didn't have a lot of initial fears. We knew what other people were doing, we knew how they were having success and we just kind of took it on faith. Here, peer-based feedback. Exactly, it was huge and you can see that here. The community is such a driver for this organization. How about self-service? We hear a lot of talk about self-service. Are you able to achieve that? How has that transformed your operation? So our initial self-service portal, we might lie with it early in April. We have about, depending on how you divide it out, about 20 different catalog items and I actually was talking to our IT director when he was out in our office and I had him come over and I just showed him a quick report and I was able to show him that since we had went live, there's been an estimated $200,000 of catalog items that have gone through the system that he had no idea about because we at least did a basic cost tracking on our catalog items. Instantly, I was able to give him feedback and he was amazed, he was floored. He didn't have any of that data before. No, nobody done. I mean, it was total of the catalog items. This is what, since we went live. It's amazing. So if you didn't buy him a Blackberry 11. That's right, Fred Lutty's talk this morning. That was awesome. Talk more about the metrics. That's sort of one example. Metrics, key performance indicators, whatever you want to call them, balanced scorecards. How have you been able to bring metrics into the equation or did you always have them? Has it changed sort of the way in which you approach metrics that are you bringing in service now? For us, the reporting out of service now is better in general. We're still kind of in our infancy around metrics, we're a very reactive organization. So the metrics are whatever we need at the time to answer the question. And that's something I'd like to get out of. I really do look forward to enhancements in the service now reporting platform though. The platform right now is good as a base but it needs some improvement. Also needs a little refresh on look and feel but it's still way, way, way better than what we have before. So we have some key performance metrics out there but generally speaking it's our help desk that maintains that. So things around agent call times and times of resolution, just the same kind of thing most people use. So talk a little bit more about what you want service now to do going forward to make your life better. I think for me personally I've been given a vision right now to try to come up with a single source of truth both for IT and for customers in a single pane of glass and that's what I need to try to figure out how to get to. That's what I want service now to help me do. Not just IT information but system performance information that I can present to the customer and say this is what your application looks like right now. Hey, you're having an issue here and give them a dashboard view into our environment so we can partner better with them and deliver better services to them. Okay, so today you're saying you've got that dashboard for IT. We got it for IT. Okay but the business guys don't have a prism into IT. And we need to bring in some metrics that aren't core in service now and make that work too. Things like those real time metrics about an environment and about the systems. We have to figure out how to make that happen and that's what I really need. So touching, if I understand it correctly, touching more of the application portfolio, is that right? You got it. Which is links to the business process which links to the business. And then understanding at the back end how's it actually performing. That's what, you know, give me a graph that says my environment is doing well. Give me a graph that says my environment's doing bad and oh look, you've got five incidents and a change don't fit on that right now. And one kind of easy to digest pane, put it on a tablet, stick it in front of them so they know what's going on. So still IT performance. Exactly. IT performance that business users are going to understand. Focused on the business users, focused on the customer, giving them direct access to know what's going on in that environment. Is that unique in terms of how service now is being used? Is that something that you're hearing from other practitioners that they're trying to get to? I think it's, there are a few vendors that are proposing that they can do it. It's always a question of which tools that you want to go with. And I would much rather service now just make that part of the portfolio. Yeah, because you're reluctant to bring in another tool, another system of record, another database. It was part of the benefit of why we went to service now is I get one vendor for all those things, or one tool for all those things. That sounds like they're all responsive, so I'm sure they're listening. We've been talking to them about it. Well, plus the other thing is, I think in class, you know what I've, we certainly, we do a lot of these events, and when you go to an event, for instance, like VMworld, and you see the ecosystem there, it's, one vendor just can't do it alone. No, absolutely not. No, you need ways to bring in other data sources in a reliable way, in a timely way. You know, you can't be stale data, otherwise it's worthless. So it has to be timely and it has to be on point. Yeah, so that seems to be happening organically within the service now ecosystem, and it seems to be more deliberate. It is, it is. But, you know, we always keep talking about Frank Slutman throwing gas on the business fire. Maybe we could see more of that on the ecosystem, because that will allow innovation to occur beyond just the sort of the bottleneck of one company. No, you got it, you got it. Great. How about advice for fellow practitioners that are thinking about making this transformation? What would you advise? Anything you do differently, if you had to do it over again? A few things that we went with our deployment were probably some bad decisions, the small things though, nothing that really delayed us too much. I would say my initial advice is, don't make the mistake of trying to make service now work in function like your old tool, or whatever you were using before. You left it for a reason, leave it behind. Take the new one, move forward. That's my biggest advice. Okay, and follow up on that. Any advice around how to, we always talk about Wikibon GRS, getting rid of stuff. Any advice on the best way to get rid of stuff? For me personally, it's been looking at what you want to do next and taking small chunks, right?  We went to project management, we got rid of the product management product. We go into catalog, we got rid of half demand management, just small iterative steps. The days of the big forklift and drop it in, they're gone. Let's just get over that and realize that we're in a very dynamic software development environment, nothing's going to be perfect. Good practice is better than the best practice if you don't have any practice. There you go. That's a good line to close. Good Neil, thanks very much for coming on, sharing your story. Another great customer story, Jeff. We continue to hear articulate, smart, fun customers. There's no place for the old curmudgeon that just wants to push the buttons anymore. I'm sure there's got to be a couple of guys that are not happy in the... It's a fun group here, it really is. I just want to get people new PCs. I don't want to be a business leader. Those days are gone. Clearly, I mean, the enthusiasm and really the, seeing this kind of business transformational opportunity for you as a personal career growth. Absolutely. As a way to impact the business is pretty exciting and that's been consistent all along the board. Really fun to see. Absolutely. All right, Neil Loffenberg, thanks very much. Thank you. Fight go, great story. Keep it right there, everybody. We'll be right back with our next guest. We're here live at Knowledge in Vegas. Right back.


Microphone is on. If no, then I will sing something because you can't hear it. The laughter tells me you can hear me. Okay. People will keep trickling in, so we'll start with introductory stuff and the entertaining things before we get to the technicals. So welcome to the first post lunch, which means most narcotic session of the whole day. I know that everybody will doze off in 10 minutes because you are all digesting. I will do my best to prevent that, but it requires a little bit of interaction on your end. I will tell you in a second. So we are talking about community fueled over the air for Sephir and other MCUs today. My name is Joseph Holtzmar. I'm the head of developer relations for Mender, slash Mender IO by Nordentech. We are a provider for over the air solutions and device life cycle management. And I have a very strong background in the Yachto project and open embedded ecosystems, which actually led me to be the new Yachto project community manager since about two months. And I also run most, if not all, of social media for Yachto and open embedded. I used to say that I'm completely antisocial, which means I am not on any social network that has kind of like changed, so I'm really, really easy to reach. When I'm around here, you just step up to me and say hi or duck or whatever it is in your local language. If it is a language that I do not speak, you can also insult me and I will say yes, that's cool man. Other than that, shoot me a mail, find me on Twitter, find me on master dawn, find me on LinkedIn. It's super easy. Just say hello Joseph. Okay, we have talked a little bit about me. Let's talk a little bit about you. Self assessment. Who of you considers himself a hardware developer? That's okay. Who considers themselves a software developer? Okay, most. Whom of the software developer considers themselves a firmware developer? Nice intersection. Who of you has also some background in embedded Linux? Yachto? For Jan Pete the ex-test? Okay, you lose man, sorry. Okay, we've got to know each other a little bit. Final question. Who has ever seen me live before? A bunch. Okay, I'll tell you how this works. This presentation is interactive. I will reward any form of interaction with chocolate until I run out of chocolate and I mean literally any kind of interaction. I have prepared a couple of examples. You can tell me what you like. That is good, that is nice. It gives me warm fuzzy feelings. That is okay. You can tell me what you don't like. That is even better because then I can improve. The best that you can do is tell me where I am wrong because then I can also learn something. You can be helpful for others. If I explain something that maybe needs some clarification, then I am convinced that others can also learn something or you can be just very, very practical and say, hey, Joseph, I want chocolate. Which counts as an interaction and I will give you. Chocolate delivery is via airmail. I have acquired some skills in throwing by now. It usually works. Sometimes it's a little bit off. Who volunteers to serve as a nap meter because if people are dozing off, then we will do some exercises to get your blood flowing again. Last bit of the organizational stuff. More details on modern tech. We have been around for quite a while. Actually for 15 years. Founded in Oslo slash bay area, San Francisco. And yeah, let's say we have been doing this for quite a while. So we think we have a little bit of a clue about it. And our mission is to secure the world's connected devices. And updates are one crucial part of this.  This is the organizational final running order. And as you can see on point two, let me introduce somebody to you. I've got a friend whose name is Joel. Joel is a man who is a very artisan side. He likes paper craft. So in the evenings, he sits down and he does scrapbooking. He prints photos, selects flowers sometimes, papers, cuts out shapes, assembles everything. And because his home is already full of those fancy pages, he has started giving those pages out to all of his friends, including me. It's super cool. I have a very special book that exists only one time on this planet. And whenever Joel gives me a page, I put it in there. And it's dear to my heart. How does this work in practice? Joel actually does not meet me very often. So whenever he has finished the page, he puts it in an envelope, seals it up, writes my address in front and puts it in the post box. Then I get it. And no more action is involved. This is pretty handy because Joel, as you can guess from the name, actually lives in France and I'm in Germany. So the only thing he does in order to provide me with a page is prepare it, drop it. Then the postal company takes care of all the rest. The postal company collects all the post boxes, sorts it, analyzes the addresses and then puts only the envelopes that are specifically for me into my post box. And for me, I don't have to care about anything. Just once a day or so, I walk out to my post box, open it up. See, oh yeah, that is for me. I process it. That's an invoice. I can get rid of it. That's just marketing. Other side getting, oh, nice page from Joel. I like that because Joel, of course, these are valuables. He always pays for proper tracking. So when the page is delivered to me, he gets a notification. Ah, has arrived at Joseph's place. Everything is fine. I'm relieved. However, with all the care Joel and me put into all of this process, occasionally something goes wrong.  Then it's set and I have to notify the postal service. They return like a knock to him and say, ah, there has been a problem with your delivery. We're super sorry. Can you just please recent or look into it? The good part about the pages is that Joel can just like figure out how to proceed. Should he repair the page? If it was returned, should he create a new one altogether? And for me, I can still enjoy the book. So the book is usable all of the time, no matter if a new page from Joel is in transit or not. You might have guessed that this is actually a story about over-the-air updates. Surprise. Because in the end, it is really just the same. You have a device somewhere out there and you have an update somewhere here. And you prepare the new firmware for shipping. You upload it to somewhere, the postal company, which takes care of all the management and figuring out which device should receive which update when, what are the conditions, what are the dependencies and everything. And then the device only receives the one update that is really meant for it. If everything works out, the acknowledgement that the deployment of the new update has been successfully applied is passed back. If something goes wrong, dwell or you get a knock, a failure, an error, a log, whatever, then you can react. The key part is that just as in the book and the pages, the over-the-air solution specifically the client on the device needs to take care of fallback and of error handling to make sure if something goes wrong during the process, the device is still functional. You can still enjoy it. As opposed to postal services, we are in software and we are open source. A postal service in most regions or even countries is a monopoly or if it's business to business or parcel service an oligopoly, but you can just say, I want my own small postal service just for this city. It's just not practical. In software, I think we should be able to do this. Let's look at the chain again. The letter, you can build software. The book, we can build devices. We had a few hardware developers in here. That's why I asked. The next thing in the chain is the service site. You can be your own postal service. This is what I'm representing here. Of course, in my presentation, I will use Mender. It is an Apache public licensed piece of infrastructure. You can just take it, use it as is, and it has a few outstanding features that make it very, very, very suitable for this kind of application because we are completely payload agnostic. If you can put it into a binary file, then we can transport it. That is the deal. You can make a blob for sefer, you can transport a docker container, you can transport a root file system, you can transport an AI model. We literally do not care. You know how to make stuff. We know how to put it onto a device. In order to facilitate all of this, the API to manage, upload, deploy is fully documented, ready for you to use, and as already pointed out, you can be your own postal service. This is not tied into a cloud somewhere. It is open source. It is on GitHub. You can just grab it and run it on your home box if you think this is a good idea, which it sometimes is. Already pointed out, the key in order to enable people to be their own postal services is documentation. For the API, because we do not lock you into a specific client, we do not lock you into a specific pipeline, we do not lock you into a specific dashboard, there is no magic hidden in there. Our dashboard does not do anything that you cannot get rid of, replace, rewrite, whatever. The documentation states each endpoint, each parameter, each response. And payload agnostic, some people say, oh, this is super special. I need to reinvent the wheel. Yet another binary thing that I can take from here to there. And we were like, no. All of the world understands tar bowls. We understand tar bowls. So let's just use tar bowls. You have to take a few small considerations into account, like the order, so you can actually stream without having to unpack everything first. But in the end, it is just using something that has been widely understood for probably like 30 years. We do hopefully not suffer not invented tears in Rome. So the last thing that is missing in my story here is the client, the mailbox that I just mentioned. This mailbox needs to be able to understand or accept the incoming artifacts. Understand means because you can't have different kinds of artifacts and you can't have different kinds of artifact receivers in the same device. With tiny ML or tenser or whatever, prominent getting to suffer also, you could basically have an update for the firmware and one for the model. There is no magic in there. The mailbox needs to be able to apply this to device in a meaningful way. And in the case of a real firmware update, in order to keep the device working, if something goes wrong, we use the AB mechanism. So apply to B, flip over. If the reboot fails, if something goes wrong, flip back. If everything works as expected, commit and make permanent. This is something that the client has to do and report if everything went fine or not. So again, you might have guessed it. Joel is a good friend of mine, but he actually has probably no idea about papercraft because he is a software developer. And all of the story was made up. I apologize, but you get the idea. Joel, end of last year, sent me a mail and he was like, your API is so easy to understand, I bet I can make it work on a microcontroller. And I said, that's a great idea. What do you need from me? He said, no, actually nothing. I just wanted to tell you. So two weeks later, I get a mail and he said, Joseph, now I got it working. Here's an ESP32 demo. You can connect it directly to Mender. I said, Joel, that's awesome. Great work. Thanks. I'm showing it to the world.  Time passes by. I make a demo. I talk to people, all of that. Out of thin air, another mail arrives and it essentially said that I have skipped a slide. Don't care. The mail essentially said, you know, Joseph, I was kind of bored. I bet I could make it work on Sefer 2. And here it is. So he decided to just grab a Sefer board, which is that one. He went for Ethernet because he felt like, okay, I've done Wi-Fi already. So this time, let's do Ethernet. And he cut it down to only one dependency, which is C-Chasen, and he uses the HDP slash embed TLS stack that is already there in Sefer. He did it originally on Sefer 3.3. Last week, he ported it to 3.4 forward. And one thing that I want to mention exactly, it's MCUboot. So he also, again, did not reinvent the wheel. He just said MCUboot can already do all of this AP flip handling. I'm going to use that. How could he do that? He actually, when he did the ESP incarnation, he had portability already in mind. So anything that is even remotely platform or hardware specific, he had carved it out. So he just needed a handler or wrapper for the communication, for writing to storage, for the thread slash process mechanisms of the specific platform, and the partition flipping. And we are super, super fast because none of you is asking for chocolate. No, no. First question, and then I'll tell you why you are wrong. You can host it for yourself. But if you do not want to do the operations, then this is what we do. So I said you can be your own postal service. I could drive around and distribute envelopes. But in most cases, I actually don't want to do that. So thank you. This is a very, very good question. And because we get that asked quite a bit, but that is actually the explanation. Even if I could do it, it's in many cases cheaper and more convenient to just pay somebody for it. And that's our offer plus some minor. And I have to tell you why you are not correct. I got the idea to throw chocolates from a C++ conference. On YouTube, actually. 2013, 2014? Seriously. Are you from Portland, Oregon? See, then it can't be you. But we'll look it up. We'll look it up. Okay. Ah, okay. No problem. It's always great to have a discussion. Even I told you, tell me if I'm wrong because that's the best. I have a demo here, which I wanted to update right now. I even brought my own ethernet, but something is wrong with the check mobile. So I cannot do a live demo right now. I'm super sorry. I will be at the tech showcase tomorrow evening. And hopefully we have wired ethernet there. And then I will show you how to update a safer board down there along with a Linux board along with an ESP32. So to just display the heterogeneous features. But I did my very best. I've been spending 40 minutes up here to get the connection working. I'm really, really sorry. We've got the most of the boring stuff out of the way right now because it seems to be working. We can update things. How to go from here? Small side track. We as Mender ourselves are currently also rewriting the client. Why? Because we have also understood the need for portability and other platforms than just Linux, where the go client has served us really, really well. And luckily, just right this morning, the first incarnation of the standalone client has been released to the world. It is very, very alpha. It serves a quite different set of requirements than the one of Dwell. It is just Linux at the moment too. We intended to go beyond Linux. Sefer is also on the roadmap. If this is something that you would be interested in discussing, testing, contributing, or maybe even working on it in a like porting or partnering situation, feel free to step up to me. You don't have to do it on the big stage. No. I just deliver one more chocolate and then I will tell you. Sorry. Pass it on. Okay. The key is yes, I know that people who think or are convinced that Rust is an excellent programming language will tell you that you can literally program with for everything in Rust and they are technically correct. However, in reality, if you get some board and some random hardware slash firmware developer, what will they have? Or a C-toolchain. So from a real practical point of view, it's a tough sell if you want to tell people, yes, this is super cool. It is written in Rust.  From an academic point of view and from the enthusiast point of view that is perfectly accurate. From the real life and industrial approach, it's just not going to fly. This is the same question as if I would ask you, why are you still writing a separate not in Rust? You will also say, because it's already there. Just rewriting it for fun because the new fad has come along, sorry, Rust, might be interesting but not realistic and that is the choice here again. So thank you for the question. You had something else? Yes. Can you repeat the question? I will repeat the question. The question is that here is a solution, a device that does not consist of a singular build or single blob of software but of a composite. Let me put on my Yachto hat for one second. In Yachto, we do this with multiconfix and then end up with a single image. Yachto hat off. Mander hat on again. You could already have done this with different packages and dependencies because Mander has a very, very advanced versioning scheme with dependencies. Provide s, version, numbers, needs, this and this and everything. Right now, you have to actually talk to the gentleman here in the first row. We are in the progress of providing a so-called orchestrator solution which does exactly that. So this was the advertising part, he does the technical part. But yes, this is a common requirement and it will be available right now or soon. Fabio tells me soon. Thank you. There was another question here. Sorry. I'll try to do better. Sorry, Harold. Closer. Closer. Yeah, you are planning to rewrite it in C++ with Sefir being on the roadmap. I have big interest in C++ and in Sefir, but I have not managed to combine them yet, like running C++ code on Sefir because it's very ingrown, so to speak. When you did this roadmap, did you think about Sefir explicitly or is it just, it looks like it supports C++? We have checked that it supports C++. The key problem with Sefir is in other areas. Let's put it like that. We are aware of the fact that the C++ that Sefir gives us is not like the C++21 that you can expect on a big POSIX or whatever. Exactly. So that's why the slide says, if you think this might be something that is of interest to you in a possibly commercial aspect, you might want to talk to us. So is that good enough as an answer? Okay. Question from the live audience and then I'll pass the mic. Supports for non-HTTP transport such as co-app, for example. Is that something that you're considering? Sorry, me sober. Clear no. At the moment and in the foreseeable future, we are strictly HTTP. Do you want chocolate or are you just a messenger? Yeah, for the live audience, for sure. I'm left handed though. There was one here. Okay. Hey, sorry if you didn't answer, if you answered this before, I came in a bit late. I have a very specific use case. So I'm deploying oil to low power devices with LoreWan. Of course, they were very limited in terms of actual throughput for the downlink, so anything coming from the server to the end device. So my question is, is there the possibility for differential updates? So you have the cloud is aware of the device having updates on so and then the update for that is sent down as a differential image instead of the full image for the AB partitions. Yes. The official client supports this in, let's say, the higher levels because this is actually a paid feature. We don't give everything away. The community client by Joel does not do it yet, but nothing is keeping you from it. So if you invest a substantial amount of like brain power to A, teach the client and B, construct the artifacts accordingly, nothing is keeping you from it. For Linux, it is there and we offer it as a paid service. More questions or shall we go on? I have one, it's at the Yachto Chester.  For updating bare metal and better things with Sapphire, can you run an update without having a second copy with the flash space is very small that you have a bootloader, which completely flushes and erases everything without having two partitions. That's what's the easy part. I would say yes, because that's why I noodled a little bit on the tar file. The tar file as artifact was constructed specifically to be able to do that. So again, Joel's client does not do it because he didn't have a need for it yet. The C client does exactly that. When a new root file system update is arriving, then it says, okay, unused partition and stream directly through to the partition. So there is no technical reason why you could not do this on a bare metal thing. It is not there yet. Again, invest either brain power or money or in some cases even both. But from a technical perspective and the API and the artifact format, this is definitely possible. I need to drink more beers. My aiming is totally off today. As the demo didn't work now, is a demo available at YouTube or so? YouTube? Not yet, but I could do one. And of course, all of the code is on GitHub. So the ESP demo is on GitHub, the Zephyr demo is on GitHub, all of our stuff is on GitHub, but I definitely can make a video of it. That's a very good idea. And again, tomorrow evening at the showcase, hopefully everything will be running. First one that I actually hit. Yes. Well, shameless plug for Zephyr webinars that I'm about to launch. I would be happy to have you and Joel maybe. I do a live demo and then we record it. Okay, but you don't get the second chocolate. Sorry. And the guy behind you just wanted to ask something. From what I heard, now the solution sounds comparable to Eclipse Hawkpit. Is that right? It is in some cases the same. So, but Eclipse Hawkpit is just the back end. You can combine Hawkpit with whatever front comes along with it or the other way around. You can combine whatever front end you love most with Hawkpit. It is a somewhat comparable solution, but again, it's just back to this question. Then you have to self-host because I'm not aware of anybody who will sell you Hawkpit with an SLA and all of this stuff. If it suits your requirements, it is a very comparable solution. If you want somebody to actually do the heavy lifting, then you might want to look at us. I'm getting better. Anymore? Not yet? Okay. Then because one of the additional things that Mender can do beyond just updates in software logistics is the so-called troubleshoot feature that we have. The troubleshoot feature gives you a port forwarding or simple file transfer, mostly end. It gives you a remote terminal. Obviously, this is something that would be very cool for Sefer 2. So, it used to be on the roadmap literally until today, 8.32. And I want to read this out aloud because it literally made my morning. Hello, Joseph. I know you are at the Sefer Summit actually. Hope this is a great moment. I can confirm it. Would like to share with you a picture attached to this email to tell you that the WebSocket troubleshoot protocol is clear after reverse engineering? Sorry. Yeah. We could do sometimes better on ducks. And I got communication between the device and the GUI of Mender. Will permit display of the Sefer terminal, my original goal, need some cleaning, et cetera, et cetera, but no more technical questions to move forward. So, I have to point this out. Joel is not on our payroll. Joel is not doing this for money. Joel is doing this after hours because he's an enthusiast. And that's what I meant with community fueled. This is a random dude who just said, this is something that is cool and I want to do it. And then I get those emails. And that's the coolest part about working in community. That people just are enthusiasts and you can empower them. So, thank you, Joel. I know this is on video and this one is for you. I already pointed out, I will bend it down at the ELC Tech Showcase. I will be having the Sefer demo. I will be having ESP32 and I will be having Beagle Play. The Beagle Play I do not want to take home with me. Can't just pass by. I will have a raffle chart. You drop in a business card. At the end of the day, I will find somebody who is pretty to draw out one of the business cards and the name on the business card gets to keep the demo, including a pre-flashed image built on Yachto with the support of TI. Thanks, Nishant. And Mandarin enabled. Raffle at 630. Wrapping up. Oh, I have a question. Sorry. I'm Abhishek from ARM. I am Abhishek. I'm from ARM. Okay. A couple of questions about delta updates. Yes. I wanted to check, basically, it's very difficult to do when the code is executing in place without virtual memory. Either you want to explain, but I would like to talk about that later to people who are discussing if this is sort of executing place environment where code is executing out of physical address space directly. Because I think that's a difficult problem and if there's a solution, I would like to understand that. If you're doing executed place, then it will be definitely problematic. So the deltas for Linux are obviously binary based on root file systems. I would guess that a delta mechanism for a flash-based microcontroller would need to be different. And that's again why it's how it circles back to artifact. We don't care how the delta looks like. You just need to have a clear identifier. So finding and constructing the technical means is one thing, but we don't say it has to be done that way. So if you need a delta B mechanism or whatever that applies to a flash microcontroller, then we can just use that as is. You can insert literally everything. I know that this is not a clear answer, but I'd say whatever somebody wants to insert, we will also happily take. I'm just going to wrap up this here, because the one thing that you should take away from this is if you are building a connected device, you need over-the-air updates. Not just because of regulation, but because I hope you take pride in doing a proper job. If you are shipping devices that you cannot fix for securities flaws or anything like this, then I think you are doing a bad job as a developer. You can avoid platform and vendor lock-in. You can pick a solution that is not locked into only Sefer or only Nix or only into this hosted solution or only into this provider. Like I said, everybody needs to make money on something. We provide that hosting, but with the APIs and everything open, it at least avoids vendor lock-in to the greatest extent possible. Open source guarantees that there is nothing hidden in there. There is no code that we can sneak in. You can revisit any piece of code that goes out to your device, and Mender is here to help you with that. We have covered a couple of questions already, and I think we are mostly out of time, right, Ben? Yes. I would love to throw more chocolates. I'm not allowed to do this on stage. I will just go out there and discuss and throw and talk to as many of you lovely people as humanly possible. Thank you very much for having me.


And then sort of have that going on, we did have an advisor steering committee and those steering committee members and also some of our key players they've moved up the ladder and so for example in Indonesia Dr. Hasil Sendering is someone who was a steering committee for eight years in IRRC but now he's a very important player in terms of policy and trying to achieve a very stretch goal of production and food security in Indonesia and he is constantly in contact with us and if we go there and don't drop in the seam if we know he knows we're in Jakarta then he'll be annoyed with us and that's very important so it's those some of those things are just builds and so and similarly with the our main counterpart they've gone up as well so that's part of it the other part too is also really invigorating that in that you know we've got someone in Vietnam who's a very important colleague and he'll be retiring in 12 months so we need now look at the next generation and we do that through the training that we do the training courses that we run here at IRI for your training center is making sure that we do have the next generation being exposed to what we're doing and so it's a number of different elements how that stacks up across the different consortium I'm not sure one quick one from Dave it's just a chance to comment on that and I think I mean certainly I'd agree that having local champions is is very important but I think you know one of one of the sort of key ingredients for successful operation within the country is actually allowing ourselves to operate within the agenda of partners so that's actually having an honest need to assist we actually asked the question well you know what do you need certainly know what we're talking about when if we're hearing the last partner say we are fed up with projects because if they come with an agenda it's not necessarily going to match the priorities of that national program and I think that is what while people intolerant um nothing you know nothing interests people more than others coming to do the same importantly I mean I think we do have an opportunity to do that because we're a very broad-based organization something what Dave is saying is that we've got a good distance and what we certainly do in country with Corrigan is we we come behind our main coordinators in country where they're to support them and raise their profile and that's all we've got time for today so thank you all for attending and please join me in thanking Geron for sending me


So, this brings us to the last talk of this session, and just 2018. It's on CIFAR, which is Exploiting Ineffective Fault Inductions on Symmetric Cryptography. It's a joint work between TUGRAZ and Infineon, and the work will be presented by Robert Primas from TUGRAZ. Okay. Hello, everyone. Thanks for the introduction. As already mentioned, I'm going to talk about CIFAR, Exploiting Ineffective Fault Inductions on Symmetric Cryptography. And I would like to start this talk with a quick outlook. So what I'm going to present is some kind of new fault attack that are quite hard to prevent in a sense that they defy both detection and infective countermeasures. And as a matter of fact, they also can cope with mask implementations. However, this is actually covered in the follow-up work, which is why I'm not really going to cover it in this talk. There was a quite versatile in a sense that they allow an attacker to induce faults at many different locations during the computation of some kind of cryptographic function. And it even works with quite a lot of different types of faults. It's even applicable to quite a large variety of symmetric schemes. And as we will see, we've evaluated this kind of fault attack on quite a variety of different platforms to basically prove that they are actually a relevant in practice. So I would like to start with a quick introduction to fault attacks and essentially countermeasures against fault attacks. So what are you doing on fault attack? Well, basically you have some kind of cryptographic implementation that you want to attack. And usually what you want to do as a first step is you want to be able to get some kind of physical access such that you can set, for example, plaintext and observe ciphertexts. Then you want to induce some kind of fault into the computation such that you can observe a possibly partially or completely erroneous ciphertext. And then what you usually do is you collect or correct ciphertext corresponding to the same plaintext and determine parts of the key by doing a guess on a subkey and performing some kind of verification based on this pair of a 40 and the correct ciphertext. Now of course this goes under the name differential fault attack and is known quite well in the community. Now usually we don't only consider attacks but also countermeasures. So how do you prevent yourself against such attacks? Well the first and probably also quite effective countermeasure would be to use some kind of redundancy to ensure that faults do not really affect the computation. So what you could do for example is instead of computing your cryptographic implementation once, you could compute it twice and at the very end simply compare the two outputs such that you only release it if actually both computations match up. By doing so you can prevent yourself against the tackles that just induce a senior fault in the computation. Now of course a attacker could do something like this and basically inject the same fault in both computations such that the result matches up and the fault is ciphertext is released. And in order to cope with that you could do things like adding more redundancy or doing encryption, decryption, redundancy, using masking, etc. Now there are also different kinds of fault countermeasures other than detection based countermeasures. For example in an infection based countermeasure what you do usually you also use some kind of redundancy but also interleave computation and usually also dummy rounds. I'm not going into too much detail here but basically the idea is that once an attacker has injected some kind of fault into a computation this countermeasure makes sure that this fault is in some sense amplified such that the output, the fault the output is not related to the key anymore. Meaning that if an attacker would try to combine again correct and the fault is ciphertext does not really a meaningful way in how to do that. Now of course there are still attacks out there that could attack such a countermeasure but they are usually quite hard and require or have high assumptions on the attacker. Apart from differential fault attacks there is also quite a few other fault attacks in literature. So for example in 2007 Clavieret or proposed ineffective fault attacks and the nice thing about those is that they actually exploit only correct ciphertext and by that I mean of course you want to check a fault somewhere but every now and then a fault isn't actually causing a run-off computation so in some sense it's quite similar to a safe error attack. The problem with this attack is that it usually requires precise faults and the effect of a fault has to be known by the attacker which is not really always the case in a practical scenario. A quite different approach would be to use statistical fault analysis as proposed by Ford R in 2013. Here the nice thing about this attack is that it works with basically any type of fault even if the attacker doesn't even know how this fault attacks affects the computation. The problem here is however that this attack can be mitigated quite easily by using for example the detection or infection based countermeasure that I have presented just before. So our idea was can we somehow combine these two approaches such that we come up with a new kind of fault attack that has these both cool properties that we solely rely on the exploitation of correct ciphertext and still can work with quite a lot of different faults even if we don't even know what they are doing. So in order to explain how this statistical ineffective fault attack works I want to stick to an example on AES. So what we can see here on the white is just the last three rounds of AES and one of the observations that we want to make here is that the distribution of state bytes for example in route nine over the course of multiple encryptions is uniformly distributed. Now that's not really surprising since AES is in pure random permutation which means that this is basically how we expect such a function to operate. Now what you want to do is now we want to use a fault somewhere between mixed columns in round eight and nine. And the goal of this fault injection is to cause some kind of non-biased sorry non-uniform distribution in some parts of this AES state for example as illustrated here. And in order to do that you have actually quite a lot of choices you can work with stocked forts, random forts, instruction skips, bit flips and even when it comes to the granularity of the fort you can target a snippet, a whole byte or even a couple of bytes. So the effect could really be something like this or like that or like that so you do not really care as an attacker as long as there is some kind of non-uniform distribution. Now as I mentioned before we want to achieve a fault attack that actually works even in the presence of fort counter measures meaning that an attacker does not really get to see any faulty output. Now an interesting observation that you can make here is that forts can even achieve this property that we observe non-uniform distribution if we just restrict ourselves to ineffective forts. So the way to think about this is that if whenever we inject a fort we may or may not receive a cipher text depending on if the fort has affected the computation or not for example in a redundancy based counter measure. So in a sense you can think about this scenario or the fort as some kind of filter that gives an attacker access to just a subset of all the possible correct cipher texts as illustrated here for example. Now how likely is it actually that an ineffective fort can cause some kind of non-uniform distribution in a state byte? In order to convince that this is actually quite likely I have prepared a very simple example. So what we can see here is just a simple end gate and we see basically two input bits that are uniformly distributed and we want to explore how forts can affect the distributions of these inputs. So just for sake of simplicity let's just forget about the output for now. And as a first example let's consider bit flips. What would happen if you have an attacker actually injects or performs a bit flip on the first operant here? Now it's actually quite easy to see that if input of an end gate here for example is uniformly distributed and a bit flip isn't really going to change its distribution. However if we restrict an attacker to only observing these scenarios when bit flip is ineffective this basically means that the other operant has to be heavily biased to a zero because every time we perform a bit flip in the first operant here this basically means that we induce some kind of difference that has to be eliminated at some point and this is only possible in this scenario if the other input is a zero for example. Now what about random forts? It's quite simple to see again that the random fort doesn't really affect the first input because by definition if we randomize a bit its distribution is still random and uniformly distributed. Now again if we just have a look at the ineffective scenarios we again see that the second input is heavily biased towards a zero and the reason for that is simply that a random fort is nothing other than just a bit flip that occurs just in 50% of the cases meaning that in a couple of cases we need a zero to compensate this difference that we have introduced and in the other cases we do not. So let's assuming that we have some kind of set of correct ciphertext that resulted from faulted encryptions. How can we actually use them to recover a key? Well that's quite easy and actually equivalent to how you would do it in a statistically faulted tag. All you need to do is you want to guess 32 bits of the round key in round ten and then basically you want to reverse back to round nine where you originally injected the fort. And then you can measure the uniformity of the state bytes using an arbitrary matrix for example in our case we used the squared Euclidean imbalance and what we should expect is for a round key candidate we should expect that all the state bytes are distributed uniformly however for a correct key candidate we should expect that the distribution of the state bytes is not uniform but actually some kind of non-uniform distribution meaning that the key candidate that corresponds to the highest non-uniform distribution or the highest SAE in this example is most likely the correct one. So let's talk about a few of the practical results that we did. So for example at first we targeted a simple software implementation from the RVR crypto lab and of course we implemented some kind of detection based counter measure that ensures that no faulted ciphertexts are released. So we injected forts via clock glitches in round nine and basically we observed that after about 1,340 encryptions we received about five correct ciphertexts. Now how can we explain these numbers? Well in this case for example our clock glitches caused some kind of stuck it forward in one of the state bytes and if you do that then intuitively a fort is only going to be ineffective in about one out of 256 cases meaning that if you want to collect about five correct ciphertexts you need about 1,300 faulted encryptions and this was enough to recover key bits for this implementation. Now we also performed the same experiment on another device for example in 88 Smeagot 256 A3. This time we didn't really target a software IS implementation but a hardware IS code processor on this macro processor. Now as you can see the numbers are quite different. The number of faulted encryptions is similar however the number of correct ciphertexts is quite different. So why would that be? Well the problem here is we don't really know what our fault actually did to this implementation here for the hardware IS code processor so we cannot really tell but all that we actually care about is that the attack works. So you can see even on quite different platforms you can achieve similar results even if you do not really know what your fault is actually doing. Now I also talked about infection counter measures at the beginning so how about them? So in order to test our attacks against infection counter measures we had a look at an implementation from Hoops and Moudre at all and here it's basically we took a software IS and on top of that we implemented this infection counter measure. So in this case for example this would mean that our IS consists of 22 riddle rounds and 11 dummy rounds and then the attack is quite the same as before. We simply try to find round nine and inject some kind of fault in there and what we can see for example in this case is that about 6,500 faulted encryptions were necessary in order to gather about two 25 correct ciphertexts which was sufficient to perform key recovery. Now you can play around with the numbers here and increase the number of dummy rounds as you like. For example if we use 22 instead of 11 dummy rounds we can see that the number of 40 encryptions that are needed for the attack increases from roughly 6,000 to 9,000 and also for 66 dummy rounds we see for example roughly 46,000 for the encryptions that are needed in order to attack such an implementation. Now in summary cipher is a new kind of fault attack that actually defines popular fault counter measures like detection and infection. It does require quite a lot more faulted encryption than for example a differential fault attack but the nice thing here is that we only need one faulted encryption, one fault per encryption independent of how much redundancy is actually used in your implementation. We also do not really need precise fault locations. There are basically a lot of choices when it comes to where we want to check the fault here. And as already shown describe the type of attack works with many different kinds of faults even if the effect isn't really known to the attacker which also makes this probably a quite competitive choice for attacks against implementations where you do not even know the implementation. Now there already exists two fall-up works to this paper and one of those was presented at SAC about a month ago. So there we had a look at authenticated encryption schemes and even though we had a specific look at sponge-based schemes there really the takeaway message here is that this kind of fault attack works against pretty much all of the authenticated encryption schemes for example or the CISO finalists, sorry CISO finalists. There is another fall-up work that will be presented at Asia Crypt and here we basically explore how this attack performs against implementations that use masking on top of having already some kind of fault countermeasure. And here the takeaway message is that it basically performs equally well with no real overhead. Even if you just hit a single share of some kind of shared implementation. So essentially this attack is independent of the degree of masking and redundancy that you are using in your cryptographic implementation. Thank you very much for your attention. So for the sake of time we'll just take one question. Hello. OK. So would a reasonable countermeasure for this attack just be that the encryption module shuts down or refuses to use the key anymore once it detects one fault in the encryption? Yes, sure. So as you have seen we need quite a lot more faulted encryptions in order to get this working for example compared to a differential fault attack. So if you have some kind of mechanism that detects a certain number of faults and it is able to shut down the device or destroy it even, this could work. Yes. OK. Yes. So one more. The differential fault attack that you showed in the pop-up please slide number three. Does it work for non-deterministic encryption schemas? Sorry for what? Does it work for non-deterministic encryption schemes? I'm not sure actually. Like when you encrypt the cycle? Encryptions with randomization. Encryption with randomization like? Non-deterministic it means when you encrypt the same plain text like multiple times you get different ciphertexts each time. Like a CVC? Oh, you mean if differential fault attack works there or if CFA works there? It's the same plain text. If you encrypt it like twice, you get different ciphertexts. Yeah. So this attack also works in this case? Yeah, sure, sure. OK. For example, if you look at the results here against authentication encryption, of course some of them are non-spaced. And you basically have to have this property that plain text is never encrypted to the same ciphertext. Yeah, so sure. Thank you. This is a ciphertext-only attack, yeah. Let's thank the speaker for the sake of time. Thank you. Thank you.