Root Causes 107: IoT Security Baseline Requirements from ETSI

Tim Callan

How are you doing today Jay?

Jason Soroko

I'm doing great, Tim. Thanks for having me.

Tim Callan

So, today, we have something very cool to talk about. We have spoken in the past about IoT security, and the reasons why oftentimes it’s lax and you know, the lack of motivation necessarily for manufacturers and users to be secure and some of the baby steps that came with, you know, California Senate Bill 327 and things along those lines, but we had a big milestone in this regard that occurred in June, which was that Etsy, published it standard and I'm just gonna get the number here, you might have it in front of you. It's EN303645.

Jason Soroko

That's a catchy one.

Tim Callan

Yes. Version - - it gets better version 2.1.1. So, Etsy, EN303645 2.1.1 and here's the title that it's been written - Cybersecurity for Consumer Internet of Things Baseline Requirements. That's a little catchier now, isn't it?

Jason Soroko

You know, what catches my eye in that title is the word consumer.

Tim Callan

Yeah, absolutely. This is, you know, Etsy's requirements for consumer IoT devices and it's really designed to address a lot of the problems that you and I have been talking about.

Jason Soroko

My goodness, Tim, you know, looking at it and it's going to take me a while to fully digest it, but my one of my first takes and this is what we wanted to share on this on the podcast was the fact that out of all the different guidances, out of all the different, you know, legal frameworks around IoT security, this is one of the ones that's not watered down.

Tim Callan

It is not. It is not watered down at all. So, one of the other things we've seen with these other, you know, rules or regulations is they're pretty weak, right? It's sort of like, instead of just doing absolutely nothing at all, we're gonna make you do some tiny little things that are unlikely to foil the bad guy anyway. This is quite comprehensive and much stronger. There are a total of 13 sections - - 13 different high-level requirements, if you will, each of which, in that section has a series of requirements.

Jason Soroko

Yeah, they use the term provisions, 13 provisions.

Tim Callan

There you go. There you go.

Jason Soroko

And there's also on the - - we're not even going to talk about that on the podcast today, but there's also a set of dialogue around data security for people as well, which is a whole other section within this document. But we're going to cover a subset of the 13 provisions.

Tim Callan

So, let’s do it. So, 13 provisions. How many of these you think are relevant to the PKI world, Jay?

Jason Soroko

I think four.

Tim Callan

Okay.

Jason Soroko

But there is a fifth, which is the first provision.

Tim Callan

Yeah.

Jason Soroko

Which is don't bloody well - - hard code username, password authentication. They literally write that as the first provision, which essentially, the California legislation is the first provision essentially.

Tim Callan

Right. Exactly. That's what we mean by these things being relatively weak. The entire - - the entirety of California legislation is more or less covered in provision 1 of 13. And yeah, the title of that provision is no universal default passwords. So—

Jason Soroko

Which is great. That's fantastic.

Tim Callan

Yeah.

Jason Soroko

I'm really glad they put it first, first and foremost. And therefore, you know, if you break that rule, then you've probably broken every other rule.

Tim Callan

Right. Yeah, you probably have and by the way, if you do use PKI, and certificate sign your devices then you've automatically met that rule. Right. So—

Jason Soroko

And it's interesting, Tim, I like to compare and contrast sometimes with other organizations such as NIST. NIST stays away from prescription the same way that you and I might want to stay away from COVID-19. Right? They're absolutely an utterly allergic to prescription and that's good. There's good reasons for doing that. I think the Europeans aren't quite as afraid, but I like the way that they're doing their prescription. They're doing it in the gentlest way possible, which is to give bold examples within the text. And so therefore, you know, they won't give you a brand names, they won’t give you a vendor names, but they definitely will give you technology types to think hard about. And that's where I think for the PKI experts that are out there, I think that the next 4 provisions that we're going to talk about, this is where some examples come out. And thank goodness it is so overdue to have a healthy discussion about, yes, this is the right way to do it in the year 2020. And it's going to be the right way to do it for a long time to.

Tim Callan

Even the no default passwords. It's not just no default passwords. It's also things like - - or no default universal passwords. It's also things like, your passwords can't be easily guessable. Right? So, having a password and incrementing the last digit by one, for instance, every time doesn't - - that doesn't meet the standards, either right? And your password needs to be able to be changed and they have got like more detail in it than that. So, you know, if you're going to use passwords, they're trying to make you use a minimum of security in that password mechanism. But so, what's the next one?

Jason Soroko

Sure, Tim, I think the next one that that we will talk about today, in fact, I'm going to bundle two together.

Tim Callan

Okay.

Jason Soroko

And I am glad that they broke them out into two separate sections because it's a wide enough subject to do so. And that's section 5.3, which is keep software updated.

Tim Callan

Okay.

Jason Soroko

And section 5.7, which is ensure software integrity. So, there's two halves of the same coin. Not only does your device have software, right, and you have to protect this integrity of that software during the lifecycle of the device. But at the - - at certain key trust points, where the software needs to be updated perhaps at the beginning of its life and midstream within its life, the device needs to have software that is updated. Both of those concepts are covered in separate provisions, and I really like the way that it has been talked about. So, section 5.3, keep software updated. You know, the most basic absolute basic thing that people need to think about from a PKI standpoint is code signing.

Tim Callan

Yeah.

Jason Soroko

If you don't code sign the update software, you're already - - it doesn't matter what you do next. It doesn't matter what's written next in the provision. Therefore, I love that, really, it's a PKI concept of signing software that is, first and foremost in that provision. You can't get away from PKI. The word PKI is, you know, the acronym PKI is not used in that provision. There's no way of getting around it. They’re essentially calling for code signing in provision 5.3, flat out.

Tim Callan

And it doesn't say PKI, but I'm going to read provision 5.3-7. The device shall use best practice cryptography to facilitate secure update mechanisms.

Jason Soroko

Oh, yes, the word cryptography appears multiple times within the document. But now let me just get on to 5.7 for a moment. And that's, you know, the second half of the story. Once your software has been updated, then how do you maintain the integrity of that software?

Tim Callan

Yeah.

Jason Soroko

And I think it's just fantastic that they're calling for secure boot.

Tim Callan

Right.

Jason Soroko

And a hardware root of trust.

Tim Callan

Yes. Yes. How about that for being lightyears ahead of what California law stipulates?

Jason Soroko

Well, not just light years, Tim, the word consumer is in the title of the document that we're talking about. So, they’re not just talking about, well, secure boot and a hardware root of trust are only for our, you know, ultimate, ultimate military level critical infrastructure. No, this is gonna –this is for teddy bears.

Tim Callan

Yeah. Doorbells.

Jason Soroko

This is for fridges. This is for doorbells. Absolutely, and why not? Because in the year 2020, Tim, the cost points for these technologies are such that they can be put into consumer IoT devices.

Tim Callan

Well, and per our earlier point that we certainly have belabored on earlier podcasts, but I guess we'll belabor it again is there is no other way. You know, there's no other economic motivation for the manufacturer of the consumer devices to include this level of security. Even if it's only pennies, even it's only oh, you know, a week of time to ship, it's pennies that they otherwise wouldn't spend. And it's a week of time to ship that they otherwise wouldn't give up. And so, you know, this is how it had to happen. Pure and simple.

Jason Soroko

This is really important, and I really hope this is the inflection point where guidance and standards and legislation really isn't afraid to call out, now here's the way to really do it.

So, Tim, I'm going to call out another provision from the document, which is section 5.4.

Tim Callan

Okay.

Jason Soroko

And let's see if there's a lot of s words in here so, I'm gonna see if I can tongue twist this - - securely store sensitive security parameters.

Tim Callan

Yeah, very good. They couldn't come up with anything with s starting for that last word parameters. There's no synonym for parameters that starts with an s? Yes. Securely stores sensitive security parameters. That is—

Jason Soroko

I think this is great, Tim.

Tim Callan

Yeah.

Jason Soroko

This is great, because it really calls out something fundamentally important, which is your device contains secrets.

Tim Callan

Yes.

Jason Soroko

Because of the fact that you're not just using some hard coded username, password - provision one already says don't do that. Well, by the time you get to provision 5.4, it's now saying, you've got to put your secrets into a secure element. And I love the way it's written because it gives you full rein, you know, TPMs, UICCs, you name it, right? There's a lot of great technologies out there, that all work with PKI and but they call out the importance, Tim, of securing an identity of the device. And that, you know, bravo. I just golf clap, because finally somebody is calling out what's fundamentally important. If you let things just unravel it's not going to work. You've got to tighten up the ship. This is the way to do it.

Tim Callan

Yeah. And so, I'm going to, quote directly provision 5.4-2: “where a hard coded unique per device identity is used in a device for security purposes, it shall be implemented in such a way it resists tampering, by means such as physical, electrical, or software.” So, there you are.

Jason Soroko

So, Tim, the next section, next provision I'd like to talk about is the other really important topic for any IoT device, which is, very few IoT devices get implemented and don't communicate, right? The whole point of IoT devices that they sense, or they control, but one way or the other, they're communicating at least at some point. So, Section 5.5, is titled communicate securely.

Tim Callan

Yeah.

Jason Soroko

And once again, Tim, they call for the usage of secure elements, because of the fact that not only are there going to be secrets in general, which are covered in 5.4 but there's going to be secrets, meaning some probably PKI certificates that need to be onboarded for the purposes of probably a TLS mutual authentication, as an example.

Tim Callan

Yeah.

Jason Soroko

And so, they're saying, not only do you gotta use those kinds of keys to securely communicate, you need to put those keys into a secure element. And that totally makes sense.

Tim Callan

Yeah. And let's be clear, that first part is required as well, right? So, here's provision 5.5-1, the consumer IoT device shall use best practice cryptography to communicate securely. So, they're not just saying that it's got to be in a secure element, but literally all the stuff, the stuff that's going in and out has to be encrypted.

Jason Soroko

Period.

Tim Callan

Yeah, period. Nothing in the clear.

Jason Soroko

I don't think people realize from a consumer IoT standpoint, that's groundbreaking.

Tim Callan

Yeah. Here's another line that jumped out at me that I really liked. 5.5-3, cryptographic agility?

Jason Soroko

Yeah. No, you got it, Tim. Go. Please continue.

Tim Callan

Cryptographic algorithms and primitives should be updatable. So, they're also requiring crypto agility. As you said.

Jason Soroko

That was my final note.

Tim Callan

Yeah, sorry.

Jason Soroko

And you are right, Tim. No, you got it. It does jump out at you doesn’t, Tim.

Tim Callan

Yeah. Holy Moses. And, you know, well-timed, because, you know, they're gonna - - we're gonna have to do a lot with our cryptography in the - - in the not that many years to come.

Jason Soroko

So, Tim, you know, I'm not going to go into too many other of the provisions, but I just wanted to put this into some context and say, you know, I've been involved in a lot of consortia work around IoT security.

Tim Callan

Yeah.

Jason Soroko

And a lot of the consortia are doing it well. You know. They're not reinventing wheels, they're, using a lot of good guidance and they're doing things almost exactly like has been specified here. So, the best of the best, are all doing things this way. I was really impressed with the Australian legislation that came out not that long ago but this one here from Etsy this has got to be one of the best I've seen so far in that it's uncompromising in terms of how it's calling for security and how to do it properly.

Tim Callan

So, what are the consequences of this? So, this has come out. This is a baseline requirement from Etsy. It's officially published. How does this now affect devices in the market? What’s the process that goes on there?

Jason Soroko

So, I really think that the closest analogy we can come to is something like NIST where it's a guidance, it's a standard off of which you can work. It's nonprescriptive. It's not legally binding. I do think, though, that in Europe, a lot of say government procurement, will basically say—

Tim Callan

Must comply with.

Jason Soroko

Here’s the standard. If you don't comply with this, we're simply not going to buy it from you.

Tim Callan

Yeah.

Jason Soroko

And therefore, you and I have talked about this on podcast multiple times, which is, as soon as a large organization that does massive procurement, like a government, says you must conform to this. Well, that's how everybody is gonna build it.

Tim Callan

Yeah, yeah.

Jason Soroko

Or they have to build it, because you're not going to build multiple skews of this—

Tim Callan

I'm not gonna have two versions, right? Just - - I'm not going to go through the trouble of having a version that doesn't have that chip in it. Exactly. It's gonna be a nightmare. And what happens if I wrongly ship the wrong product to the wrong thing and it's a supply chain nightmare and it's a distribution nightmare. Yeah, no, they're just gonna say, okay, this is what we're doing.

Jason Soroko

I'm an IoT device manufacturer in North America, I'm small. This has nothing to do with me. Wrong. The chance of you selling your equipment into Europe is quite high and so therefore, these provisions do apply to you. So therefore, I think this is going to raise the bar globally. I mean, that's me being as optimistic as possible, but it could potentially have that effect.

Tim Callan

Yeah. So, it's exciting. And our, um, I think not just - - you talked about like a government procurement. But also, doesn't this wind up being a real strong roadmap for other people who are making regulations or guidelines, or consortia who are putting together their guidelines, it's going to be real obvious the same way a lot of people use NIST - - it's gonna be real obvious for people to go and Etsy has already done the hard work for them, and say, okay, I'm gonna start here.

Jason Soroko

Tim, this this is what gets me is I've even seen some NIST documents, and God love them, right? They're doing some good, good work. But if even some of the language within some of the IoT guidance for NIST is, well, if it's really, really constrained, you don't have to worry about this, you don't have to worry about that and you can feel the hand ringing.

Tim Callan

Yeah.

Jason Soroko

You know, and this document, flat out says, even for consumer level devices - -

Tim Callan

Yeah.

Jason Soroko

- - this is what you need to do. And this is the first - - one of the first documents I've seen so far that talks about even the lowest level device from an economic standpoint. Let's even just not talk about risk for a moment, just from a pure economic standpoint, the lowest level device really should be treated to proper baseline security. And this is it. This is how to accomplish that. PKI is at the center of it and it's a very well written, well considered, well thought out and I think, Tim, to really answer your question, if you're having trouble, you know, as a legislator, as a guidance writer, or as a security architect of your own IoT device, this whole geez, you know, I need to save a quarter of a penny per million.

Tim Callan

Right?

Jason Soroko

Okay, great. You know. Valid argument, but, you know, if I'm writing guidance, geez, you know, do I have to kowtow to everybody who is afraid of, you know, secure boot? You know, even though it's the best idea since sliced cheese. Well, no, don't compromise anymore, guys.

Tim Callan

Yeah. Well, what's nice is now it gives them license not to compromise, right? Because if I've got a consumer device and I've got this incredible price pressure and I'm saying well, you know, the other guy's gonna be underselling me by $1 and I've got to find a dollars’ worth of savings so I can be sitting at the same price point. Now, the other guy has to do this too, right? So, the other guy also needs to include secure boot, and also needs to include a, you know, a protected hardware module and so as a result, everybody will have the same ground rules. Right? And, you know, they'll still be trying to get to the lowest price they can but those devices will include these capabilities by virtue of the fact that they will have to.

Jason Soroko

Exactly right, Tim. You know, I just got a thought, which is, I would really love to reach out to some of the authors of this document.

Tim Callan

Oh, let's do.

Jason Soroko

And really ask the question, you know, why - - what allowed you to be so properly bold at this point in time? You know, first of all, congratulations. But, you know, what's your message to the rest of the world that feels that this is too much?

Tim Callan

Yeah. Yeah. That's - - let's do that. Let's see if we get an answer. And if so, we'll put it on the podcast.

Jason Soroko

There's a lot here, Tim. And I think if you're a PKI - - somebody who is interested in the field, interested in how it interacts with IoT, or even in how it interacts from a networking, authentication standpoint, just in general, it's a good document and it it's not overly complex—

Tim Callan

No.

Jason Soroko

And it's not it's not underwritten as well in that it has zero prescription. I think it strikes the right balance.

Tim Callan

Absolutely. Like it's very readable. It's extremely readable and yet, at the same time, it's not at all devoid of information. It's quite packed with information.

Jason Soroko

This one is one of the clearest I've ever seen from that organization and that's why I’d really love to talk to some of these authors.

Tim Callan

Alright. So, any last thoughts on this, Jay?

Jason Soroko

No, Tim, except to say thanks for letting us bring this up and we're gonna keep an eye on it.

Tim Callan

We'll definitely keep an eye on it. Thank you, Listeners. I think this is a topic that this isn't the last time we're going to talk about this and we'll see how it's developing and what happens. But that's it for today. So—

Jason Soroko

Thank you, Tim.

Tim Callan

Thanks. This has been Root Causes.