Edge AI Security: Why Secure-by-Design Engineering Matters

Speaker A: The old rules remain so secure by design. Uh, and I think, uh, that will be key, and you need to start there. Hardware and software is part of the equation and the ecosystem. You cannot just, uh, think on one, uh, and not on the other.

Speaker B: Um.

Speaker C: On this episode of Embedded Insiders, Ken sits down with Kuldesky Labs senior Vice President leading the go to market team, Christoph Nichols. The 2 discuss Edge AI security, and they dive into the company's secure by design engineering approach that helps manufacturers develop and deploy products safely through the entire life cycle. Next, Rich and Steve Hanna, a distinguished engineer at Infineon, discuss the crossroads between embedded devices needing updates and patches for bugs and security vulnerabilities, and the fact that these devices may not have the memory space to do so. What do you do? Hello, everyone, and welcome back to the Embedded Insiders Podcast. I am assistant Managing Editor Tierra Oliver, and this week Ken is away at an event with nxp. I was away at an event last week with Microchip, so be sure to tune in to next week's podcast to hear our recap about both events. In the meantime, just wanted to give you guys some information about an upcoming event, a, uh, virtual event hosted by Embedded Computing Design. And it's AI at the Edge Day. It's coming up soon. It'll be happening on September 3rd, so be sure to look in the description of this podcast to register. If you attend this event, you'll have the chance to hear from industry experts who are actively working on real time edge AI, analog and sensor fusion, networking and connectivity, and much more. So you don't want to miss out. But that's all I have for you today. As another reminder, the upcoming interview and this podcast will be Posted on our YouTube if you rather watch it instead of listen. And as always, remember to, like, subscribe, comment, share your thoughts. Um, we'd love to hear from you guys. That's all for now. Now here's kristof nichols of kuldesky labs.

Speaker D: Hello, friends, engineers, and embedded professionals all over the world. Welcome to another segment here on Embedded Insiders Podcast. I am Ken Briota, Editor in Chief of Embedded Computing Design, and very happy that you're all joining us today, whether it be here on YouTube or on your favorite podcasting platform. Uh, I am here today very happy to be with Christoph Nicholas of Kudelski Labs, and we're going to talk about, well, just the hottest topic in embedded these days, Edge AI Security. Christoph, welcome.

Speaker E: Thank you.

Speaker A: Thank you, Ken. And thank you for having me.

Speaker D: Uh, the pleasure is entirely mine. And if somehow my audience doesn't already know who you are, they're about to find out. It's their pleasure as well. Can you tell us a little bit about yourself and about what Kudelski Labs does?

Speaker A: Sure. Uh, so first on my side I'm a software engineer by background, uh studying my careers about 30 years ago in Kudelski already at the. So I really uh, feel and sounds like a dinosaur uh nowadays uh, developing embedded uh, software for uh, uh eight bits, 6805 smart, uh card based processor, uh at the time there, uh, in the media security divisions of the Kudeski Group, uh where at the times we are fighting piracy into uh, set the box, uh satellite broadcast. So if you are old enough you can remember that uh, interesting times where uh, we were at the forefront of what age uh today. And it was not AI, but it was definitely a security topic already at the time. So did my career uh within Kulesky, uh starting with that media security, then moving to cybersecurity. I started the cybersecurity business for the group and then now I am both the group cio. So I have my uh, uh head in the cloud and in AI, but still the foot in the ground because I'm adding the go to market of the Kuleski Labs which is the innovation security arm um of the group. So our uh, visions and our missions is to look at what we call frontier technology. So AI being one but also quantum post quantum technology and making sure that we can have our customer adopting those technology in a secure and safe way.

Speaker D: Absolutely. And that's what we're going to be talking about today. I mean I think everybody knows that Kudelski has been a watchword for security and cybersecurity since forever, functionally. And it's no surprise to hear that uh, you guys are elbows deep in edge AI security. So let's start with uh, the big ones. What's keeping you up at night? What scares you in Edge AI security? Because it can't be the old, tell me it's not the old IoT stuff again where it's just the unsecured edge devices creating botnets to scare us all.

Speaker A: I think everyone being in the software development those days might be scared by the adoption of AI in the software development lifecycle. I think the embedded sites might be a bit more protected than uh, the rest but uh, definitely that transformation, that disruption is all over the place when you see especially uh, in the recent weeks, uh some new models mitos being announced there, uh, you see that uh, probably the capability. The seniority in cybersecurity in security engineering is now uh, at the fingertips of any um, bad guys that wants to use that uh, on your software. So what keeps me up at night those days is not only that our secure by design approach is uh, definitely important and more and more important those days, but it means that not only the security experts will be able to look uh, at your software, but anyone soon and therefore the mix of the software and hardware will be important. I think you mentioned that in one of your recent postcards uh, on the co design between software and hardware. So for security it was definitely something to be taken into account. But nowadays security software and hardware targets needs to be taken seriously and um, should be at the first thing uh, that you need to address.

Speaker D: Yeah, I think uh, I mean it's so funny. As long as I've been writing about and covering security it seems like a lot of times the old rules are the best. It's always a moving target. You do your best to patch any holes that you find, repair any bugs and uh, try uh, to stay nimble at all times. And today, although it's immeasurably more complicated than it was 20 or 30 years ago because the attack surface is so much wider and everything else it's still those same fundamentals, right? You just make sure that you're trying to well think of everything. Uh, you know the thing that I'm curious about, especially with respect to Edge AI, you know, if you think about old school bad actors in the 80s and 90s, it was hardware. You know, they would be hands on, walking into a facility and plugging into a thing in order to tap in. And that was way before anybody was trying to remotely log in or any of those things. Remote. We're quite good at software cybersecurity now. I think that's fair to say that's become a much harder target. And now we're creating giant hardware, uh, infrastructure not just in terms of these data centers for AI that are being built, but also the entire edge is, is becoming smarter. And is that hardware side of the equation the more sort of dynamic attack surface now is that, is that sort of cycling back around?

Speaker A: It's clearly I think uh, enhancing the capability of the Edge which is a glass half full, uh, very exciting. You can do much more on the Edge. You can have uh, not only the mc, uh doing part of the job, but you have also GPU, TPUs or dedicated hardware that will enhance uh, what you can do there. Uh, but uh, it's also increasing the risk and the complexity of uh, doing a proper software. So a software today might be not uh, only uh, your main uh, MCU software, but also uh, what uh your model will do, your inference data, uh, and you need to think maybe broadly on what to protect and how to protect uh, uh, an execution at the edge because uh, all of that capability will give us capability to uh, take autonomous decisions hopefully uh, very soon at the edge. And that's where security and safety uh, is becoming a uh, very, very key part of your uh, secure by design approach. So do you really trust an autonomous car that is taking decisions? So I think now we are getting used to it, at least for the one living in the US we see the way most of those world crossing around with our driver. But what if it's only uh, your car but also those quadruped uh, robots, those humanoid robots that will share your uh, daily life or even share your household. So it's one thing to be um, if you don't like it, you can stay away from uh, the highway or from the car driving alone. Uh, if that will be your white goods or your robots doing things at home, uh, you need to make sure that that will be uh, uh, safe and you need to make sure that you can also maintain the uh, security, the model and the data, uh, uh, in a safe way.

Speaker D: Yep. Um, you know it's funny, I just wrote in my first Waymo, uh like a month ago I had, I had sort of avoided it for a long time just because it didn't come up. And I was down in Austin for a uh, small new show called Microelectronics Us uh back in uh, April and it was a nice little show and Uber gave me the option and I was like well all right, I'll try it. I will say it was very weird the first time. I like to drive and it's very strange to have no one driving. And then just like anything else it became normalized very quickly. Uh, my only complaint was I didn't think it's a very good driver. It's far too timid, which I want. That's not a complaint. It's just that I want it to be as careful as possible. But at the same time I'm like well just go,

Speaker A: yeah, I did, I did, I did the same about months or so but in Arizona. So you know, uh, living in Europe, you need to move back to your uh, Apple Store Us uh, Apple Store to enable the things I was not crazy enough to uh, enable the beta testing on the highway. But uh, because the law of physics, if you crash at 60 miles per hour, uh, the damage is a bit different at that. Sorry. But uh, definitely an interesting experience and yes, it will become the new normal. Uh, uh, but still, if you have engineering background, there is still a lot happening there to make it happen. And sometimes it's a bit scary, uh, to say the least.

Speaker D: Absolutely. You know, uh, with increased complexity is increased opportunity for uh, fault. Um, and I think it's fair to say, just to bring us back on topic, uh, as I always digress, uh, I think it's fair to say that when it comes to security, whether we've been talking about cybersecurity, hardware security, edge, AI, whatever, the biggest risk is always accident, not bad actor.

Speaker E: Right.

Speaker D: I think that's fair to say. It's more often that you've got data leakage than data theft. It's more often that uh, you know, somebody accidentally leaves a port open and that's how something happens that nobody intended is. And that always felt to me as a uh, as just a journalist, not an engineer, like an inevitability that there's just going to be those things at some point. Even if there were no bad actors of any kind, there's no hackers, there's nobody out there trying to gain access to anybody's system, there's still going to be accidents like that. With a, with the complexity of the Edge AI system that we have today and it's only growing more and more complex, um, how do we sort of help to ameliorate that risk, that risk of accident, that risk of unintended consequence?

Speaker A: Yeah, I think again, and we are probably biased on that but security uh, by design is probably the only viable path forward. So you cannot think about security after the fact there because again as soon as AGI will enable autonomous decisions there, your goods are becoming. It starts with how do you identify uh, that thing? It's not an IP address, uh, or a Mac address that you can spoof. Uh, you need to make sure that you give capability, you give decision power to your sink, uh, and you keep uh, IT identified. We see in the IT world uh, how difficult it was to move from uh, password to passwordless to uh, zero trust aspect. So just think about the same in uh, billions. And then uh, your things will be not only one id, uh, but multiple ID behaving on your behalf or with you at the same time. So that's the first things to take into account. The security lifecycle management, uh, has been also a topic for us uh, we have been the first one in the 90s to use flash memory into set top box and we were looking like full because it was too expensive. And I think you discussed about the cost of the memory uh nowadays for the rams but at the times we are just look like how come do you want to update a software in a TV set? And nowadays I think it's the new normal, uh, but it will become more and more important to do it in a safe and secure way. So all of what we have been doing uh for critical product, uh secure boots, secure attestations, making sure that uh you have all the cryptographic uh toolings in hardware uh to do it I think will be paramount. If I can hack into your software, you need still to have that secure base somewhere that you can rely upon and that will uh, take care of your identity, of your key secret and manage uh, your software download and your safe way to be back to normal if uh, you're under attack or if you have a leakage.

Speaker B: Mhm. Um.

Speaker D: Uh there are two areas that I want to reach into that are a little bit speculative I think but I'd love to hear your thoughts about them. The, the first is sort of with respect to bad actors, counterattack infrastructure. You know it seems like that's not been the sort of strategy by and large for a long time. It's mostly defensive or uh, uh, you know, repair after the fact kind of kind of strategy. Um and I'm curious why is that? And the other area that I want to talk about is uh, simulation digital twin with respect to security. Not just defensively but in terms of attackers. Are they using simulation technology, digital twin technology to plot methods of finding breaches and uh, how big a problem is that?

Speaker A: No, I think that's a good point and I think maybe agent and model will help us to uh, automate some of those uh hunting that we are doing typically on both on the embedded world in our security labs. That's exactly what we are doing. We make sure that we attack our product and then we hunt for bugs. Uh not just doing some code review but also using all the hardware and software capab ability to attack. And that's also just to link that to I think uh, what keeps me up at night uh those days metos is exactly that. I think there were a good uh paper published two days ago about Cloudflare and it's the first kind of feedback of uh, um, a tech savvy, security savvy company that uh, went through the project Glasswind and what they've learned out of it. So learning and hunting using metos was very helpful. Trying to fix uh the issue using metos was not so helpful because I think created other issue or other aspects. So definitely uh looking uh at your digital twin, looking at your software using uh that as the kind of the sandbox to test uh the things to look and hunt for weaknesses to maybe test also the patches uh uh and the fixes will be more important. I think one of the challenges uh and I was debating with a group of CISO yesterday, even if you test an LLM based or AGI based solutions uh fully before deploying it, uh you never know how much of that uh LLM will be stable in the time because uh I don't feel that uh my uh, uh preferred cloud opus LLM is not moving during over time. So it's evolving over time. So maybe uh that prompt injection that you have tried against the LLMs, uh that was not successful might be successful tomorrow and you have not changed a single line of code around it. So that complexify a bit. Uh, what and how do I test my model? So we were debating yesterday and say okay maybe the continuous type of uh pen testing, uh built in pen testing capability and on every product and solutions that's maybe the way forward if you think about it.

Speaker D: Yeah, you just opened a door that I'm going to turn into a teaser to try and bend your arm to come back on this podcast and discuss something later on which is LLMs and how I believe they cannot be secure and should not ever be treated as secure and therefore shouldn't be allowed in secure systems. It's one of my many problems with LLMs as a rule. Um, but uh, that I think is another discussion and an argument whether or not.

Speaker A: Yeah I agree but also people have been very naive. I think the good news with LLM is that they are so good at solving part of the user interface you can talk to your thing and that's very cool and for the first times behaving almost as expected. But on the other front is um, I was taking that example, um, if the briefing of your user interface LLM is please the end user they will do stupid things and you should onboard your LLM a bit more like uh, you will never put a junior software engineer uh in short of your full production uh CI CD until you have fully onboarded the new engineer and everybody will agree with some seniority or some experience there but they're putting an LLM unbriefed to do your user interface or to code on your software stack without any brief. It seems that part of the population still think that's the way to go. And yes to your point, then that's the beginning of the end.

Speaker D: Yeah, absolutely. Well, uh, Christoph, thank you so much for taking the time to chat with me today. Uh, I'm definitely going to have to try and get you back on. There's as always, a million topics to cover. Uh, when it comes to security, it's an ever moving target and I don't envy you all and your Sisyphean task of attempting to keep up.

Speaker A: Uh, yeah, no, as you said, I think uh, the old rules remain so secure by design. Uh, and I think uh, that will be key and you need to stop there. Hardware and software is part of the equation and the ecosystem, you cannot just uh, think on one, uh, and not on the other. Uh, both at the design level, but also more specifically at the security architecture level. And AI is enabling a lot of opportunities, but uh, is complexifying the model and you need to look at the full ecosystem and lifecycle management of your solutions if you want to survive.

Speaker D: Absolutely. Uh, anyone who's, anyone who has heard of Kudelski and Kudelski Labs, but uh, where should they go to find out more and uh, are there ways to engage with you guys?

Speaker A: Yeah. So I think uh, maybe you should ask your preferred agents to look at that. I'm pretty sure they will find that uh, kudeskillabs.com is one way to go. We are also in uh, a lot of trade show. I think we bump into each other at uh, CS Embedded World and uh, we did ISC west this year. So we'll be in a couple of uh, trade show until the end of the year and back at CS also next year. So looking forward to uh, to meet with you. And we are bringing robotics and we are putting in motions, uh, some of our thinking and visions, uh, to make sure that people do understand and are interested about security. Uh, and I think robotics is a great uh, conduit for that because people then see the risk more than just think about the risk.

Speaker D: Uh, next time I see you, I'll have to remember I've got a uh, brand new intrusion tool that I've been playing with that I think you'll really like. It's called a hammer and it works literally every time. Uh folks out there, thank you so much for joining us for this conversation. Uh, as always, please, uh, subscribe if you haven't already. Thank you for watching us. If you're catching us on YouTube, or if you're listening to this on your favorite podcasting platform. In the meantime, I'm Ken Briota, editor in chief, Embedded Computing Design, and I've been your host. Thank you so much to, uh, Christoph Nicholas and Kudelski Labs for joining me today.

Speaker A: Thank you again. Thank you, everyone. Bye.

Speaker E: Bye.

Speaker D: Have a great day, everybody.

Speaker C: Now here's Steve Hanna of Infineon.

Speaker B: Good afternoon and welcome to the Embedded Executive Podcast. My name is Rich Ness. I am with Embedded Computing Design. This week we have, uh, a pretty regular guest now, Steve Hanna, distinguished engineer from Infineon. How are you doing, Steve? Dave.

Speaker E: Doing great, Rich.

Speaker B: Um, I gotta say there's two reasons why you keep coming back. One is that the topics that you're an expert in are so close to what the audience does. And secondly, I've always said you have this knack for being able to explain things that, um, taking super complicated subjects and making them understandable for people at all levels of technology. And I thank you for that.

Speaker A: That.

Speaker E: Well, thank you, Rich. I sure enjoy it.

Speaker B: So the subject today is something that you and I had a discussion about, and I said, this is something we should do a podcast about. Um, when you have an embedded device, you're. You're constantly updating it to make sure, um, for lots of reasons, but one of those is security. For sure, you need to make sure that you have the, the latest security on your device. So you're continually updating these patches onto your device. Sometimes you're talking about devices that have been out in the field for quite some time. So my question to you at the time was, well, you don't have infinite space to keep uploading these patches. At some point you're going to run out of memory space. Then what do you do? And, and I know when I posed that, you got a big smile on your face because this is, this is not something that, um, is new to you, but it's certainly new to me, and I'm. I'm guessing it's new to the audience. What's the answer? I don't think there's an easy button you push to fix here.

Speaker E: Uh, there's no magic easy button here. But, uh, this is a topic that concerns all of us because, you know, as we all know, software just seems to get fatter and fatter. And, uh, even if you're not adding new features, you're fixing bugs and security vulnerabilities, and that just makes the software a little fatter. Every time you do a firmware update, it's gotten a lot Worse in the last few months because we've realized all of a sudden AI now has the ability to find cybersecurity vulnerabilities at an incredible rate. And, uh, we're seeing, uh, 10x increase in open source projects, uh, having to patch vulnerabilities, sometimes even more than 10x. So when you decide, is that a

Speaker B: good thing or a bad thing? I mean, are we just finding the bugs faster?

Speaker E: Well, you could argue it's a great thing. We want to find those bugs and fix them. On the other hand, it's not so good. If I shipped a product a few years ago expecting I was going to fix 10 bugs a year, you know, 10 security vulnerabilities, do 10 patches, and now I'm doing 100, now I could easily run out of patch space long before the lifespan of the product is exceeded. So.

Speaker B: But do you ship a product with the expectation of having to fix bugs? Like, I mean, aren't engineers perfectionists? And you say, I don't have any bugs in here? You're introducing something completely different now, saying, well, I know I'm going to have to fix X number of bugs.

Speaker E: Oh, come on, Rich. You know, in your first engineering project in school, you discovered that you were not perfect when you wrote your first code and it wouldn't even compile. So, yeah, I think we all know, or should know that, uh, there are bugs in all software and some of those bugs are security vulnerabilities that need to be fixed. So I hope you plan on some level of patches. But the problem is it's now 10 times as many patches as you planned on. So you're going to run out of patch space 10 times faster than you thought because your software is just going to be growing enormously and rapidly. So that's the problem. And go ahead.

Speaker B: Uh, okay, that's, uh, the problem. What's the solution?

Speaker E: Well, basically, you have to put your firmware on a diet. It's not easy, it's painful, like dieting always is. But here are the steps that you can use. Number one, you can look for ways to shrink your code size. Now, you probably did some of this before you shipped the product originally, but there are always opportunities. Stripping out software that's not needed, changing your compiler flags, that's an easy thing to do. Just tell the compiler to optimize for space, not speed, and then recompile. As long as you're not building real time systems, that's not a problem. You can, uh, potentially find some dead code, uh, and take that out. Um, for Example, maybe in your build you have some software that's just not used, some, some programs that you might even think about stripping out certain features that are very rarely used. Uh, another thing you can do, and this can be a great way to find extra space that you can trim, is to shrink your data size. Because a lot of times there's actually more data than code, static data, things like string files, um, or if you include any sort of graphics, videos or sounds, we have any sort of user interface in your product like that, uh, those can get really large and you might compress them more tightly or just get rid of that stuff. Because we're talking about embedded systems here, you know, maybe you didn't need that. Another thing that you can do that people don't think about is move from having a global, uh, software image to having one per region. That way you don't have to have all the translated versions of the strings in your software, but just the one local version. Um, other things that you can do make your software update process more space efficient. I want to talk more about that, but not right now. Um, also if you get to the point where, you know, I've squeezed it as much as I can and I'm still running out of memory, you might prioritize your bug fixes and put in the ones that are really severe and prioritize those first. You might even strip out some of the bug fixes you put in before. Um, and if you find a situation that you've done everything you can and you still can't fix these security vulnerabilities, then you have a device which is effectively permanently vulnerable. Um, and you have options even there. You could, for example, say we're going to strip out certain features, we're going to remove the web browser from the smart fridge, we're going to take out some of those features so that we can still continue providing security patches for this. Especially if you made a promise to your customers that you keep on making security updates for a 10 year period and now suddenly you find yourself, uh, up the creek, so to speak. Uh, that's an option for you.

Speaker B: Are you making an assumption that the person doing the patches, who's uploading the patches is technically astute. Who's able to do these things that you're talking about? Because a lot of times you might just have some administrator who just knows that he hits, uh, an update button and it happens automatically.

Speaker E: Yeah, I agree. I'm thinking that the, the person, in my experience, the person who's writing embedded systems firmware is technically a student, and that's the person who has the opportunity to take these steps. Uh, you know, you have to be pretty good at writing firmware to get it to run on an embedded system. Sometimes you have to write machine language or assembly language, you know, device drivers, things like that. So, you know, you, you're, you're, you're pretty well up there if you're writing embedded system software. Uh, now that's not the person who's pushing the software updates out to the update server, but, uh, that is the person, your software developer, your firmware developer, who's going to have to make these tough calls about how to squeeze things.

Speaker B: What about adding more memory? Um, I'm a little surprised that you didn't offer that as a potential solution.

Speaker E: With most embedded systems, if it's already out in the field, that's not an option. You're not going to ship the customer a new motherboard or, you know, uh, add memory to something that's out in the field. You might be able to do it for a new spin of your product. Yes. Uh, but not for things that are in the field.

Speaker B: Okay, so I'm out of space. I know my system is vulnerable. Do I just lay low and keep my fingers crossed? No.

Speaker E: At that point, you need to notify your customers about the problem. And then you have to decide, are you going to EOL the device? Um, or take, uh, one of those other options that I talked about, removing features from it. Then you can fit the security updates, um, squeezing it, putting on a diet. Sure. Then you can do that. If it turns out that it's unsafe, you might have to remotely brick the product. But I do want to get back to that thing I mentioned about changing your secure your firmware update process. A lot of embedded systems use what's called a B updates, where there are two copies of the firmware on the system at any one time. There's the active one, and then there's an extra that you're uploading the firmware update into. That way, if somebody turns off the power while you're uploading the, you know, downloading the firmware update into that extra copy. Well, you, you haven't heard anything. The active version is still fine. People have tendency to do stupid things like that. Um, so, uh, that's an ab update system. You download the new version into your set, your B slot, and then you reboot and go with trying out the new version. And if it works, great. And if it doesn't, you fall back to the A slot. Well, that Requires two full copies of the firmware image in memory. And if you're doing that, there's an opportunity here to put, put the second copy on a DIA so that you can have copy A, be the full firmware copy B, be a slim version of the firmware which is just designed to go out and get a new copy of the of slot A. So you're, you're requiring effectively two firmware update steps in order to do a full firmware update. But with this clever mechanism, you could have say, uh, almost double the size of your firmware without running out of memory. It, ah, doesn't always work, but you know, it, it depends on how you're designed it, but it can help.

Speaker B: You're not suggesting going from an AB update to just A and getting rid of B altogether?

Speaker E: No, because then your reliability is out the window. I'm just suggesting that you alternate full featured update with tiny update whose only purpose is to download the next full featured update. I think you see what I mean.

Speaker B: Yep. Yeah, I was just looking to use the cross my fingers method one more time.

Speaker E: I wouldn't advise it. You're going to have a lot more customer support calls when people pulled the plug at the wrong time because they were frustrated.

Speaker B: Do you see today's designs going out with a lot more memory just for this reason than we did previously?

Speaker E: Yes, absolutely. Because we can see the trajectory that, uh, firmware updates are coming more frequently, security vulnerabilities are coming more frequently, and therefore we need to budget for more rapid growth in software firmware size. Of course, it's not just about, uh, firmware. There are other things that you need to store, like keys, and you need to store those into a secure MCU like the PSOC Edge, or a security chip like the Optiga Trust M. But really the firmware issue and the, um, shall we say obesity issue really mainly applies, uh, just to firmware.

Speaker B: Very good, very good. This is, um, a very important topic and, um, I'm really glad we were able to cover this. I think people really need to understand what the issue is here.

Speaker E: Yeah, if it hasn't hit you yet, it will be AI is coming for your firmware just the way it might be coming for your job.

Speaker B: Ah, the topic for the next podcast. Very good. Thank you very much, Steve. As I said, um, you describe this in a way that pretty much everybody can understand.

Speaker E: Yeah, we're all fighting the battle of the bulge one way or another.

Speaker B: That was Steve Hannah, a distinguished engineer with Infineon, and I'm Rich Nass, with embedded computing design.

Speaker C: Thanks for listening to this edition of Embedded Insiders. For more daily news, videos and podcasts, visit our website at embeddedcomputing.

Speaker A: Com.