Internet of Things ecosystem

Episode 251: Kry10 CEO Boyd Multerer on building a secure OS for the IoT

In this episode of the podcast, host Paul Roberts speaks with Boyd Multerer, CEO of the firm Kry10 about the firm’s technology: a secure operating system for the Internet of Things and about how the challenges of managing modern, connected devices demands new tools and platforms for securing those devices.

[Video Podcast[MP3] | [Transcript]

The Internet of Things is growing – and fast. Data from the firm IoT Analytics  shows that the number of global IoT connections grew by 18% in 2022 to 14.3 billion active IoT endpoints.  By 2027, there will likely be more than 29 billion IoT connections, the firm says. 

Unfortunately for consumers, businesses and governments alike: all those billions of devices sit on a shaky foundation. A study of the security of IoT devices by Phosphorus Labs, a cybersecurity company, found that 68% of devices studied contained high-risk or critical software vulnerabilities. That’s consistent with a 2020 study by Palo Alto Networks that found that 57% of IoT devices are vulnerable to medium- or high-severity attacks

Boyd Multerer, Kry10
Boyd Multerer is the CEO of Kry10

And, as software and always on Internet connectivity extend to a greater range of endpoints, the stakes are getting higher. Sophisticated, cyber physical devices running on general purpose operating systems like Linux create untold opportunities for mischief. As an example, there are the recent revelations of remotely exploitable flaws in vehicle telematics software which raise the specter of cyber physical attacks in which software based attacks cause damage to persons and property. 

This growing population of smart, connected and cyber physical devices demands a new and more secure platform from which to operate – one designed with next generation, smart cyber physical devices in mind. And that’s what our guest today says he’s developed. Boyd Multerer is the CEO and founder of Kry10 (pronounced “Cry Ten”), a company that has developed a highly secure operating system for smart, connected devices in mission critical settings. The Kry10 platform is billed as a zero trust architecture that is capable of limiting the code that can run in privileged mode and isolate  non-core capabilities as possible.

In this conversation, I talk with Boyd about Kry10’s technology and the challenge of securing the modern IoT and how the challenges of managing modern, connected devices demands new tools and platforms for securing those devices. To start off, I asked Boyd to talk about his journey through cybersecurity and how his work in the early 2000s as an engineer at Microsoft tasked with developing the company’s massively popular XBOX  and XBOX Live gaming platform informed his current work about securing IoT devices.

Video Podcast

Episode Transcript

Paul Roberts (Security Ledger): Okay, so we’re back here in Security Ledger Studios. I’m your host, Paul Roberts, back for another episode of the Security Ledger. And with us in the studio, we’re really happy to have Boyd Multerer, Boyd is founder CEO of Kry10, really cool. IoT, security Startup Boyd.

You’ve got a really interesting history and a really impressive kind of biography. Tell the audience a little bit, our listeners a little bit about yourself.

Boyd Multerer Kry10: It’s really good to be here. A little bit about myself.

I actually didn’t come from a software background. I came from manufacturing and from factories and have a degree in mechanical engineering. So I always thought I was gonna be a mechanical engineer, but found myself drawn to the software part where there’s like fast turnarounds. And as you go through a career of that building, first desktop publishing and then web servers and all that, you find yourself dealing with more and more security issues as we get more and more connected. So around 2000, I joined the Xbox team and helped build Xbox Live and then XMA, which was to developer program, and then the Xbox One operating system.

And the lesson you learned through all of that is that, Where you think you’re gonna build a strip down PC that plays games, you actually end up building something that looks more like an industrial device that is real single purpose and focus on a certain area. And it’s got both physical attack vectors and it’s got software attack vectors, and it’s just a very different mindset.

And then after Microsoft and after all that you reflect and, I realized, oh wait, physical, so physical vectors, software vectors, it’s all industrial and there were patterns there that could learn from.

Paul Roberts (Security Ledger): Going back [00:02:00] in your history you, actually started off focused on like the desktop publishing space, right?

Boyd Multerer Kry10: Yeah.

Paul Roberts (Security Ledger): how do you find your way to the Xbox team back in 2000, which was I guess probably the origins of the, of Xbox as a product.

Boyd Multerer Kry10: Sometimes careers look like a random walk, but then you realize they’re not later on. coming outta mechanical engineering school, I, I don’t know, I saw flaws in PageMaker that I wanted to go help fix, so I wrote stuff that worked in desktop publishing. This is in the nineties. If you go look up old, PageMaker books, you’ll find me in them. And then I did some contracts with Microsoft and met Jay Allard through about 1994. So he was busy trying to turn Microsoft into something that embraced open web protocols, http. So that come 96, I had already built up a relationship with, Jay and just about the time that That Adobe came in and about all this and all that happened, I found myself [00:03:00] doing a contract working on IIS 3, which was Microsoft’s first web server, early web server. And once you see that, you’re like, oh, this is going to replace desktop publishing,

So core philosophy you build for where the world’s going and not for where it is. So I made a decision at that time. Web wasn’t taking off yet, but I could see it would. So I dropped the desktop publishing and went in the web, and that was really fortuitous because three years later, Jay has spun up the young Xbox team and he asked me to come in and go figure out.

The way he put it was after much debate, we put an ethernet port in the box and not a modem. Go figure out what it talks to.

Paul Roberts (Security Ledger): What was your, answer to that,

Boyd Multerer Kry10: you have to do the same exercise. Where’s the world going? At the time, there was no broadband. It was like talking ISD online and really low penetration, but you can see where it was going.

So let’s go build a ScaleOut web service that has, that’s built for hundreds of [00:04:00] millions of devices that are managed locally, but can be configured. Not manage centrally, but can be configured locally. We had to deal with attack patterns that range from hardware analyzer, logic analyzers down to people trying to hack safe games on, storage media. So as soon as you go down that path you, find it’s, quite a deep hole.

Paul Roberts (Security Ledger): That became Xbox Live, basically, right?

Boyd Multerer Kry10: Yeah, it became Xbox Live. It had tendrils into the os the what we did in 360 in Xbox One was then we took it a layer down even lower into the hardware. There’s transistors in the SOC (System on Chip) to support those systems going back upwards. And that became really informative as to what are the techniques you use to protect industry.

Paul Roberts (Security Ledger): One of the interesting things about Xbox is that the content* *on Xbox is highly valuable, right?

So you’ve got these games that are very desirable and that are a population of people [00:05:00] globally very interested in pirating them so that they can use them and run them for free. That’s always been the case. Same thing with music and film, right? This is what the D M C A was actually created to protect was this type of content very valuable, very sought after.

Boyd Multerer Kry10: there’s two reasons. People attack a game console. That’s one of them. So one is to, play free material or to get around paying licenses. The second is, to cheat, to win. And they’re, very different attack vectors.

Paul Roberts (Security Ledger): Talk about how they’re different.

Boyd Multerer Kry10: in the play free in the play free content version, the attacker isn’t they’re not trying to change the experience. What the attacker wants to do is they wanna sell you a, multi terabyte hard drive with every game on it and sell it to you for 80 bucks. They’re selling software by weight. Right? So they’re looking for physical attacks that can defeat the cryptography, that checks that a game is valid, [00:06:00] that checks that is on valid media. The cheat to win… there’s all kinds of different vectors that you could try to look at. Some of the early ones that we saw that we, that were a little easier to defeat would be like a network sniffer. Maybe I’m running a perfectly valid game, but if I have a PC next to it and I can have a top-down view of where all the players are in the game, I get a information advantage.

Or if I’m in a game and I’m losing, can I pull the network cable out of the wall and cause the session to fail and now it’s not recorded as a loss, right? All the way to people glitching hardware, where if you drop the voltage on a pin at the right time, you can clear a register and that changes. The values that are going through at a certain point in time, so that’s much, much harder cause you have very tight timing channels and requires a soldering iron.

But the, set of things that you have to do are, quite different between the two. So you have to really understand your threat model.

Paul Roberts (Security Ledger): How did that affect your thinking as an engineer working on that team? Cuz most in the security space you’re [00:07:00] usually, yeah, you’re, you might spend most of your career really focused on one type of threat actor

Boyd Multerer Kry10: Right.

Paul Roberts (Security Ledger): or one, or, a, a pretty small set of threat scenarios.

this is like constantly evolving. First of all, you’re continuing to issue new consoles, right? And new games and new features. Then the, obviously each of those kind of spawns new attacks and new efforts

Boyd Multerer Kry10: so how did it affect me? If you look at the, when we started with the career path, you start doing desktop publishing and UI work, and then you start doing you start working on web servers. And my role there was managing public private key crypto cryptography on the website. And then you start thinking about how to lock down a data center, and then you think about a hundred million devices that are connected to it.

How do you show that the kernel hasn’t been patched? And then you start realizing, oh geez, now I’ve got these physical attacks that are happening. And then those things are timing where they’re actually measuring instructions. And next thing you’ve got people working for you who are doing FPGA work [00:08:00] and like blowing fuses and making sure you can’t roll back and you’ve got lots of keying.

So it’s been a constant education as you go. And now I find myself worrying about everything from. Protecting data once it’s in the field to, if you have a, collection of devices and you’re trying to manage permissions on them, it becomes a permissioning nightmare. Your attack vectors start to become human, right?

Where if I can game the people putting permissions on because their job is too hard, now I can take over a set of devices without violating the rules, right? And you go from there all the way down to worrying about leakage across an L1 cache between applications. So Specter and Meltdown are still things that we have to worry about and we have to design in as we’re designed for, as we’re building systems.

Paul Roberts (Security Ledger): Can we talk about the, just the internet of things space more broadly as it exists [00:09:00] today? We’ve got tens of billions of iot devices connected globally. most of those are low value low or no security devices get ’em to market focus on features and, it’s just it’s, a real mess out there security-wise. What, are your thoughts on why that is and where, do you see the real kind of problems right now with the iot deployments that are out there?

Boyd Multerer Kry10: let’s start by looking at the shape of the IOT devices, what we think of when we say iot. We tend to think of really small devices. Maybe they have an r m processor, like an M four or something. They do a single job, maybe they have a single thread running. They don’t even really have an os. It’s like a little RTOS thing.

Read a piece of data, maybe take a simple action, [00:10:00] maybe send some data up, and that’s about it. For those devices, those will they’re, battery constrained and they’re cost constrained, and that’s a class of device that will be out there for a long time. But we have to understand its limitations.

What’s interesting to me is the new class that’s emerging right now, which is a bigger device, it’s on minimum like an Army seven, so it’s got a proper CPU on it. It’s got half a gig, of RAM it’s got multiple threads, multiple applications, multiple jobs that are running at the same time. So think I’m collecting data, I’m storing and managing that data.

I have an AI model running. I may have a separate application, a second AI model running that’s doing a different set of reactions based on it. And they have different update patterns, or my data collection can never stop, but I’m constantly resetting and updating the AI model. It’s still a device in the field, so it’s still got the shape of there’s not a human [00:11:00] there, it’s in the field doing a job.

And it’s still true that the job it’s doing is worth more than the device, but they’re getting inherently more complex. And I personally think that the really small, many of the small iot devices will start to go away. They’ll still be a market for really little things, but they’ll be connected to a bigger one.

More of the logic will be running on the bigger one, and maybe that bigger one will be controlling like 10 or 20 of the small ones. So you have to think about where’s my logic running? And if a, fault happens anywhere in the logic, and I don’t care if it’s an attack or if it’s just an error, or if it’s a bug, what’s the damage that, that attack, that fault can cause?

And what are the consequences of that fault, right? So really you have to think differently. As soon as things get more complicated, you have to think very differently about how you isolate and how you contain and how you deal with, the damage of a fault.

Paul Roberts (Security Ledger): but my sense is those [00:12:00] conversations probably aren’t happen. Maybe they’re happening in some contexts medical devices, maybe automobiles, things like that. I don’t necessarily get the sense that those types of conversations are happening.

Boyd Multerer Kry10: that’s because we’re at the turning point right now, and I think as I’ve talked to people, we’re already there and not everyone sees it yet.

But I’m surprised by the number of companies who have already had to contend with these things. Any place where you’re collecting complex information and then making decisions based on it where you have to update that decision matrix are already there and this could be true for a door camera that also unlocks the door to your house. It’s definitely true in automotive, massive once in a generation shift happening in automotive right now, ECUs are basically going away and it’s becoming a central computer. Central computer is a large, complex device.

We have to isolate the components on it and worry about the damage that, how to put it. [00:13:00] You don’t want a fault in the radio. To cause your safety systems to malfunction.

Paul Roberts (Security Ledger): as with Miller and Valasek, basically,

Boyd Multerer Kry10: Yeah, that’s right. So you have to really worry about those connections. The isolation between components. Although there’s reasons now they have to be on a central computer, cuz as soon as you have high definition images floating around that you’re doing analysis of, you need the bandwidth you need, you can’t have it be a local network.

The, an RMM isn’t going to, isn’t gonna cut it. You need A7, A8, A9, something higher.

Paul Roberts (Security Ledger): Let’s talk a little bit about Kry10 and sort of the origins of the company.

Many of these devices that we’re talking about are running on, as you put it, operating systems from, platforms from the last century, which is absolutely true. Which is definitely true.

Most of ’em are Linux or maybe even embedded windows, depending on what types of devices you’re talking about. And kind of general purpose operating systems. [00:14:00] So talk about what you thought saw as the opportunity here and, what led you to stand up Kry10.

Boyd Multerer Kry10: so we’ll talk a little bit about the story and understand that. We’re still in a, we’re in a phase now where we’ve built a new thing and sometimes it’s hard to exactly describe it. So even we’re landing on our language for exactly what is it, and I’ll do my best to describe it to you. First observation you have when you leave a company like Microsoft, you have to go and scan the world around.

You look at all kinds of other tech, right? And I found two pieces of tech that were super interesting and that informed some of these. Decision. The first one was the ERLANG Beam, which is from Erickson Corp. Beautiful piece of code. What they teach in the Beam and languages be like ERLANG or ERLIXER.

What they really teach is how to break your code up into pieces so that you do the minimum amount of work to recover from a fault. That’s really [00:15:00] what it is.

And this is why telephone systems are all built on this thing, and they measure the uptime in decades. Like they don’t talk about how many nines in a year.

They talk about how many nines in a decade, and it better there better not be any, it better be a hundred.

So they’ve shown how to build systems that you can update. You can keep them going, and you can recover from a fault without having the whole thing go down. At the same time. I heard about a piece of tech out of Australia called SEL 4.

Now this is a microkernel. Now this does go back to the nineties. Actually, so does ERLANG, that goes back to 86. But the debate in 92 was, are operating systems gonna go down a microkernel path or a monolithic kernel path? And in a monolithic kernel, drivers live in the kernel. So when you install like a printer driver, you have to put your password in.

You’re effectively acknowledging Yes, I really mean to install this thing because it’s going into your kernel. [00:16:00] If it crashes, your machinery reboot, right? There’s no really good isolation. And yes, there’s new advances in hardware to try and create some, but it’s still, it’s a big blob of code that is sitting there together with millions of lines from who knows where, running in the most sensitive part of your computer.

So you take on a lot of risk when you have a monolithic kernel, but you gain performance.

Versus a microkernel where you separate that risk, everything lives as an application, but now you have a performance penalty. And in 92, when it was Pentium chips, that performance penalty was a big deal.

Now it’s 2023 and it’s not

There’s better intrinsics, they’re faster. It’s not 8,000 cycles that go between user and kernel mode is like 80. And the, and chips are just so much faster. So that performance thing is no longer an issue. Now it’s momentum. So when you think about devices, you look for areas where you [00:17:00] get to have a reset conversation about what should an osb and in devices, there’s not a huge amount of legacy there.

Yes, people have written code in Linux, but that’s more about the a p i than it is about the kernel itself. So you get to have that reset. You get to talk about micro kernels, you get to talk about capabilities and ways of having APIs that you can refactor and you can build new things in.

And then you look at latest pieces of tech. And the, thing that really blew my mind was formal methods, which is if you have that microkernel, you have to believe it’s correct. You have to believe it works.

And the only way to do that, is you use formal mathematics to prove that is correct.

And once you’re there and you can believe it, you can start to do some truly new things.

Paul Roberts (Security Ledger): So, just explain for our listeners, when we’re talking about formal methods what, are you’re, what are you talking about? You’re really talking about mathematically proving that software works as it is designed to work and doesn’t[00:18:00] behaviors that that are not accounted for.

Boyd Multerer Kry10: Yeah, that’s right. So this is really about testing way, this isn’t so much about writing the code, it’s about knowing that your code, the code you wrote is right. In normal testing you’ll write a function and then you’ll write some tests that call it, with some values that should give a good answer.

Call values. That should cause a bad answer. And then you check to see if you got the values you expected. And it’s probably gonna work if it does, but you didn’t check every value.

It would take a lot of time. So informal methods, what they do is first they, build what’s called a, they basically specify, they build a specification for logic in pure math. And the tool they use is the Isabel proof assistant, which if you haven’t seen it, you should go look it up. It’s, fascinating. There’s a language inside called Isabel Hall for called higher order logic. And you can literally write programs using mathematics and you, [00:19:00] it’s not really programming, it’s a proof.

You’re writing a proof in pure math and that proof, the shape of the proof can describe logic and then you can make claims about it because it is a proof you can show, Hey, there is no way this thing can buffer, overrun. There is no way that there can be a dere you can dereference a null pointer.

There is no way you can do all these other classes of things. And then below it you write C code to implement the spec. But because you’re in math land, you can write a proof showing that the C code is a correct implementation of the spec.

And then you write another proof that says, I don’t trust the compiler.

How do I know the compiler didn’t inject it in an attack? Or, how do I know the compiler didn’t misinterpret my C code? So then you take the output of the compiler. And you can prove that is a valid implementation of the C code

All the way down. So now I’ve got a binary that runs in the machine that I [00:20:00] know is a correct implementation of the spec and that, and I know that the spec has these properties.

This is new. Effectively what it does is it tests all possible inputs at the same time. Like the thing that’s exciting about Quantum is it can like test all possible keys against an encryption algorithm at once. This effectively tests all possible inputs to a function at the same time.

It’s just extremely hard to do

Paul Roberts (Security Ledger): And resource intensive.

Boyd Multerer Kry10: human resource intensive. You need math. You need mathematicians who can think about logic and can write this stuff. So the kernel that we use is SCL 4, and that’s the thing that’s thematically proven and it has what’s called the capabilities interface, which is beautiful cuz it’s, very composable, right?

Paul Roberts (Security Ledger): So the advantages of using it for an a company like Kry10 are that you can basically go out and assert [00:21:00] this is a secure architecture and secure environment.

Boyd Multerer Kry10: Basically, yeah. There’s always caveats. I have to assume the hard the hardware works is specified.

And effectively what it allows us to do is we can create sandboxes for other code,

and those sandboxes are the things that are backed by the formal proofs. So I can load informal code, I can load normally tested code into one of these sandboxes, into a least privileged sandbox.

It’ll execute, and even in the event of a full takeover. Someone has completely taken over the code and they fully own execution inside the sandbox. They cannot break out of the sandbox. That’s the point.

Paul Roberts (Security Ledger): Powerful.

Boyd Multerer Kry10: Powerful, right? So now let’s say I’m in a vehicle and use a real example. It happened in Seattle like about a year ago.

Bad metadata comes down on a song that’s playing on the radio, it causes, it caused the music app [00:22:00] to crash and it crashed it away. It

took the whole head unit.

Paul Roberts (Security Ledger): This is a Toyota? That if I recall

Boyd Multerer Kry10: It was Mazda, it was my favorite radio station. Yeah, my whole favorite radio station malformed metadata. The head unit crashed. It took the whole head unit down.

That should not happen. You, it’s fine if the radio player has an issue, but it can’t take down mapping and it can’t take down your phone call

Take down system control. Or those have to be isolated from each other, even though they’re running on the same computer.

So that’s what we’re talking about, using the formal methods to back up that isolation.

Paul Roberts (Security Ledger): So Kry10, this is in some ways you are on the front edge of, as you a sort of an emerging trend. But most. Manufacturers invested in the hardware and software and architecture that they’ve got. they might be looking to incrementally improve the security.[00:23:00]

really coming to them and saying no We wanna shift the whole paradigm. Hard conversation to have.

Boyd Multerer Kry10: It’s a hard conversation and it’s hard to explain. For a company like us, what you look for is companies customers who are already at the point where they have a problem and they don’t see a way through it, right? So the shape is someone who’s building a device that maybe used to be simple, but they’re being forced to combine that, combine them onto one computer, or because they’re bringing in AI onto these suffices, they’re no longer simple like, the, a lot of golf courses now, the lawnmowers that mow the lawn are, there’s no human on it.

They’re like little robots that, go around the whole thing. And they mow the, course and they come back to the barn and charge themselves up at the end of the day.

Paul Roberts (Security Ledger): Sure. Yeah. John Deere has an autonomous tractor, right?

Boyd Multerer Kry10: Yeah. How do you know that the That the mower control, the navigation control, the looking for humans [00:24:00] walking around bits, the talking to the radio, the updating, the the communications back to home base.

How do you know that they’re not interfering with each other? How do you know that someone can’t take it over vehicles of all kinds when you’re looking at cars as well? Massive change. ECUs are shrinking the little real-time units and the software used to be on them is now components on a central computer.

It’s got that flavor right. They need something new. So when I talk to car companies, the car, the conversation’s yeah we, have a problem. We can’t use anything that’s out there today. It was all built for this physical separation model, and now they’re combined and we still need the separation.

Yeah. So there’s a, you look for places where there’s a massive shift like that. And that gives you a place to come in and have that conversation. If I tried to do this 10 years ago, I don’t think the market would’ve been ready, but it is ready now. We’re finding those conversations and not everybody’s there, but I think they will be.

Paul Roberts (Security Ledger): What, are the security benefits of this? When we look at attacks on IoT devices, most of them are, not happening at the kernel level, right? These are trivial exploits of vulnerabilities injection attacks, buffer overflows That, that type of thing. That’s a kind of boil the ocean problem. How do you get, software developers to create more secure code? But will, having a platform like Kry10 make it make the consequences of those more mundane security problems less?

Boyd Multerer Kry10: Yeah, that’s getting there. So as a platform, We wanna make it so that if you’re using our systems and we care a lot about the tools and making it so it’s really easy to get things started. As a developer, I always hated beginning a new project where you spend the first three days just trying to [00:26:00] get the tools to compile, right?

I want this to say, Hey, I’m building a new device, and it spits out a system that’s ready to start running. You just start adding your business logic, but the thing it spits out is by default. Built in a way where there’s sandboxes that are defined by lease privileges that you start putting your code into.

Now your code is still your code and I can’t help you be a better coder and all that, but I can contain the work you’re doing and prevent it from attacking, from affecting the next container. So, really what I’m doing here is I’m trying to shift the conversation away from here’s a bunch of apps.

And toward, here’s a bunch of risk buckets. I have containers that run code in them. And the point is that any one of these containers may have an error and it may get go down and it may need to be restarted,

I want to [00:27:00] know that it can’t Cause the next container sit the container sitting next to it to have the same tab, an error.

So you allow the system designer, the device designer, to start thinking in terms of pools of risk and where you put in your various bits of code if, hey, here’s a driver and here’s some software. And if either one fails, they have to be restarted together, you might put it in the same bucket,

Right? But the more you can separate. The more you have the ability to restart into a known good state with minimum effort. I want updates like the downtime from an uptake to be on like the a hundred millisecond range. I want recovery from an app failure to be in the 10 millisecond range. All right? Already from a cold boot because you’ve eliminated so much.

Even turn the power off and turn it back on. We’re looking at like second subsecond. So you, change the nature of the discussion to be less about writing apps, which is an a monolithic OS concept, and more about what’s your risk containers [00:28:00] and what are the connections between them. Cuz every time you allow them to talk to each other, that’s a way risk can leak from one container to the other.

So from a security perspective, it really changes the way you think about your device.

Paul Roberts (Security Ledger): What who’s your competition? Are these are, you going up against the NXP of the world the, chip designers themselves? Silicon designers themselves, or Intels or or is this more of a I, don’t know. Who who’s out there? Who is

Boyd Multerer Kry10: That’s great question. It’s a great question. I definitely don’t think it’s the chip designers.

Okay. We need the chips in order to run, and I view them very much as partners, like we run really well on NXP chips. Any chip where the proofs have gone all the way down to the ISA is something that we. Run well on.

So we’re like [00:29:00] today we’re focused mostly on ARM 64 and risk 5 64. There’s efforts going on to get the 32 bit versions working. I do X 86 if there’s enough devices that want to use ’em. There’s it’s, about supply and demand, right?

When you think about other operating systems, like who’s the competition?

If you say, you could say, Hey, if we’re about security, there’s things that are about security. If you say it’s about uptime, there’s things that are about uptime. If you say it’s about remote management, there’s things about remote management. What you struggle with is to find anyone else who’s really solving the combination of them.

So it, I think what we’re doing is we’re defining a new category here,

Devices that have a certain amount of flexibility, and they have a certain amount of zero trust built into the architecture. At a deep, level, who has, who can do the updates, who’s got the key material to authorize an update, that kind of thing, along with [00:30:00] isolation for apps.

But that isolation is defined by the person who has the key material. So not anybody can change. Who’s got the permission to change which apps and which buckets, and what those risk factors are, has to be controlled all the way with cryptography up, up, and down the stack. So it’s, a holistic view of it and I don’t see anybody who’s really in there.

If I had to say who’s my biggest worry, it’s complacency. And to me, complacency is to defined as good enough. Linux as a, nah, it’s good enough. We’ll just use it. Except when lives are on the line or when your business is on the line. Whatever the job the device is doing is on the line, then you realize, eh, I’m not gonna worry about it.

Isn’t good enough.

Paul Roberts (Security Ledger): That is an issue cuz we there, there’s certainly been ample evidence that there are real security problems with the internet of things. That there is a of vulnerable devices [00:31:00] out there potentially with kind of cyber physical consequences to failures or interruptions. And yet maybe with the exception of the electric grid we have not seen a robust.

Policy response. I’m speaking to you from North America, United States. Certainly not a focused one. And, that’s, I think that’s true everywhere. Ultimately companies often do things when they’ve got that regulatory kind of gun to their head and they have to do them.

Do, you see that as being the game changer? That type of thou shalt.

Boyd Multerer Kry10: Great question with great timing. So right now being debated is the European Cyber Resilience Act. This is. This is game changing. This thing describes the consequences. If you put out a device that you fail to update, [00:32:00] if you put out a device that has no one bugs in it, if you’re not at the top of your game and that device fails and someone dies, your board has liabilities. It actually goes further, and this is where more of the con, more of the controversy is if you contribute to open source. And your contribution has a flaw on it and you don’t bother to fix it and someone else dies because of that, you might be liable. So the open source community is up in arms right now cuz it, it threatens the entire open source model.

And at first the rea, my first reaction was, that doesn’t seem right. But then you remember, wait, no, we are talking about devices, not PCs. We’re not talking about servers. And we’re not talking about your PC or your phone. If the server goes down, we’ve got clusters and we can restart it. And you’ve got general availability.

We understand that problem. But if this is a device that’s running your ventilator, if this is a device that’s, controlling the safety systems in your car, there’s [00:33:00] very different consequences. And maybe it does require a different bar. I don’t know the proper name of it, but it’s often referred to as the Biden Cyber Resilience Act.

Also changes the rules. Australia just announced they’re retooling their entire cyber legal framework. The UK is in the middle of it.

You’re right that we haven’t seen a lot of response yet. The thing is, it’s all in flight right now. All these legal frameworks are in the middle of changing and you’re, it is gonna be, it’s basically going to be mandated that you’re at the top of your game.

And I think. What I’ve read about the European one is a little smart. They’re not saying this is what you have to do. They’re saying this is the consequences if you don’t.

Paul Roberts (Security Ledger): Okay. Final question. So we’ve got a lot of cybersecurity people in our audience. If they are working on a product team or working in a product development group maybe on an iot type device, and they’re like, huh, that sounds interesting, how can they connect with Kry10 and [00:34:00] learn more about your technology?

Boyd Multerer Kry10: The fastest way is there’s a little form you fill out on the website, so, k-r-y 1-0-dot-com. Fill out a little form and we’ll, jump on that. The real thing you need to do is just think hard about your threat model. And think hard about what is the complexity of the software on the device that you’re building.

As soon as you’ve got bits of software that have to be running mixed with bits of software that you wanna update, that’s a new pattern. That’s one we have to wrap our heads around, and that’s like specifically what we’re targeting. If this is a little arm M thing and it’s doing one job and it’s so simplistic that you’re not worried about it.

And that’s, a different conversation, but as soon as it becomes more complicated, then we would love to be there to help you.

Paul Roberts (Security Ledger): and as you said, those more complicated, more robust, more powerful devices are becoming the, norm rather

Boyd Multerer Kry10: I think there’ll be more than norm than not. [00:35:00] Yeah.

Paul Roberts (Security Ledger): Multerer, thank you so much for coming on and speaking to us on The Security Ledger podcast. It was really great talking to you.

Boyd Multerer Kry10: That was great talking to you too.

Paul Roberts (Security Ledger): We’ll have to have you on again,

Boyd Multerer Kry10: Okay, thank you.

Comments are closed.