Perhaps recognizing that they just can’t solve all this IoT-device security stuff alone, we are beginning to see movement by IoT device manufacturers to look to security platform and IT security experts to help enable device security end-to-end — from manufacture to implementation in the field.

This past May, CA (Certificate Authority) and security solutions company Sectigo (formerly Comodo CA) acquired Icon Labs, a provider of cross-platform security solutions for embedded OEMs and IoT device manufacturers. Yes, it is about expansion, but it also, perhaps, a way of addressing the mounting concerns around not only hardware-device security but, increasingly, around the ever-vulnerable software security issues associated with millions or billions of connected devices. Security has not historically been a core competency of device manufacturers, so the question is, do they learn it and do it themselves or find partnerships with companies like Sectigo?

In this two-part interview, we sat down with Jason Soroko, CTO of IoT for Sectigo, and Alan Grau, former president and owner of Icon Labs and now VP of IoT/Embedded solutions at Sectigo, to get a better perspective on not only what this acquisition means to the company and their customers but also what they see as the biggest challenges in IoT security.

To better understand this acquisition and the two company’s relationship to one another, let’s get some background on Sectigo.

Jason: We adopted the name Sectigo at the end of November 2018. The company itself originated as a company called Comodo CA back in October 2017 when the equity firm Francisco Partners purchased the Public Key Infrastructure (PKI) assets from Comodo Cyber Security, an organization which still exists today and which sells endpoint security and some other solutions, as well. We are a completely separate entity, but we are the PKI assets from that sale.

Sectigo is currently the world’s largest commercial issuer of SSL certificates — public trust certificates for the web. It’s a considerable portion of our business. We sell primarily through web hosting service providers; however, we also have a significant amount of business with large enterprises, as well. That’s the public trust side of the business.

More interesting in the context of this acquisition is the private trust side of the business. One of the products we have is something called Sectigo Security Manager, which is essentially a cloud-based PKI for enterprises for everything from traditional authentication up to DevOps and IoT. For IoT, we have our issuance platform called IoT Manager. IoT Manager is a purpose-built, cloud-based certificate issuance system for IoT devices.

While we were discussing that product to large IoT device vendors who are interested in X.509 certificate management and issuance for their IoT devices, quite a lot of them were asking me questions such as, “Hey, can you, at the same time, offer us secure boot? Can you do things such as an embedded firewall? Are you able to perform some more advanced or custom provisioning for me for certificate lifecycle?” All of these things that were being asked for were embedded security software solutions.

As I said, we’re a trusted third-party CA. That means that a lot of companies will come to us when they’re looking to do IoT for interoperability or if they want to have trust extended across product lines. Essentially, any time you want to have a trust model with your certificates that extends across some boundary, whether it’s a corporate boundary, a network boundary, you name it, we can help by hosting a root of trust for PKI or standing up PKI infrastructure. But we’re also very good at issuance and at setting up trust models — all those things that a proper PKI will give you that a traditional security company cannot.

So, we began looking around the marketplace and found Icon Labs. I had heard of them from previous work I had done at another company. We met Alan and, within a relatively short period, we completed the acquisition. Icon Labs is now a wholly-owned company within Sectigo. The Icon Labs name will remain as a brand so that when you purchase the embedded software products that Icon Labs is known for, those products will be fully backed up and supported by Sectigo.

Alan, as the president and founder of Icon Labs, what was the attraction in working with, well, being acquired by Sectigo? Were their offerings something that you noticed your own customers were interested in?

Alan: Actually, that very much is the case. There are a couple of things that our customers were asking for. For one, many of the OEMs that we are talking to are large multinational companies. They were, quite frankly, in some cases, concerned about our size. As Jason said, Icon Labs is now backed up by Sectigo, and that gives a level of comfort to those larger organizations that we were dealing with. That was one key piece of it. The other thing that was an issue for us is we had robust products on the embedded side, but customers were saying, “Great, we’ve got secure boot, we’ve got a firewall, we’ve got the ability to do protection of our data and strong authentication using certificates, but now we need to be able to manage certificates.” We had started to build out our own PKI infrastructure from a very different point of view from what Sectigo was doing. We’d built an on-premise certificate authority product that companies could use to manage certificates within a constrained location.

To take it to the next level, to where Sectigo is, was to build out that strong infrastructure, cloud presence, and operational processes in terms of maintaining a well-protected root of trust in a cold, offline storage vault. Those were things that were well beyond the scope of what we were able to bring to the table. But it was very complimentary to what we needed and what our customers were looking for.

Let’s talk a bit about Certificate Authority (CA) a phrase that is not historically part of the engineer’s vernacular, although it is becoming increasingly so. Can you simplify the concept?

Alan:  I’ll explain like I would explain to my mom when she’s trying to understand what I do.

A certificate is like a driver’s license. It says who you are. You’ve got all these devices, whether they’re websites or IoT devices, and you need to know who they are. A certificate solves that problem and function. We trust a driver’s license because it’s issued by the state of Iowa, or California, or whomever. We inherently trust the state to issue these identities and to have a process for doing so securely. Those entities are continually going through and refining their security processes to make it more difficult to create fake IDs, to counterfeit these devices.

The same thing is analogous in the world of a Certificate Authority. You trust the CA because, inherently, you have to trust somebody, and the CA companies have been assigned as trusted entities. Companies like Sectigo have done an outstanding job of figuring out how to do issuance in a way that’s strong, secure, and very difficult to counterfeit or to clone those certificates.

We hear about on-premise CA and cloud-based CA. Can you clarify that, as well, in the context of CAs?

Alan: On-premise versus cloud-based CA comes down to the usage model. If you look at traditional services requiring certificates, you’re talking about websites and things that are publicly available, publicly online, and so they can go to a public source like Sectigo to get a certificate. If you’re looking at an IoT device, in many cases, that model still works. You may have a manufacturing facility where you’re going to inject certificates into the device when they’re manufactured, and that manufacturing facility is online and can request those certificates from a cloud-based system.

In some cases, though, customers want to ensure that they can handle that process locally without having to go back to the cloud or having to require Internet connectivity. There they can use a subordinate CA installed on-premise to injecting certificates and managing certificates, and this can be done inside the factory. That’s kind of an extension of Sectigo’s use case that overlaps with Icon Labs. That’s why we are starting to talk to people about putting a CA in a factory for them.

Another interesting case is a closed industrial system or closed system of some type. Think of a building control system, an airplane, a military ship, or a large passenger ship. That would be another use case for PKI issuance on-premise. Every device in the ship or the airplane can have their certificates managed by a CA located within that closed system.

Then what is the need for certificates versus other forms of security?

Jason: Certificates support many use cases. One of the primary use cases is to set up a TLS encrypted communication session. Essentially, the analogy is the same as when you connect to an HTTPS website. The web browser is setting up an encrypted tunnel between the web browser and the web server. The same thing can happen on an IoT device. The communication between the IoT device and perhaps the cloud or some other edge device will be encrypted using TLS. With HTTPS websites only one end of the connection, the website, has a certificate for authentication.

Another use case is TLS mutual authentication. In other words, the device itself can go off and mutually authenticate itself to another device or the cloud.  In this scenario, both ends of the connection have a certificate and authenticate to each other, hence the term mutual authentication.

All that said, the world today is lacking a lot of PKI infrastructure required to support IoT devices. That goes for everything from industrial systems to healthcare. To me, it’s a little bit scandalous just how little security there is in a lot of these things. Take a look at the Mirai botnet which is an almost perfect examples of the problem with static credentials, whether it’s a static username and password or a static shared secret, also sometimes known as a symmetric token which is just a string of alphanumeric characters. The reason why it’s called symmetric or shared is that the same alphanumeric string used by both ends of the connections, both the IoT device, as well as whatever it’s trying to authenticate to. It’s just like if you and I wanted to do business together and I said, “Come to my house tomorrow, knock on my door three times, and then I’ll know it’s you.” That’s essentially a shared secret.

There are several problems with these static credentials and shared secrets. IoT devices are quite often made with the exact default symmetric token or username and password. That’s why the Mirai botnet was able to harvest millions of devices on day one — there was virtually no security.  “Admin, password123” was the default, and it was able to plug this into millions of devices and compromise all of them. Legislation has now come out in California, in Texas, as well as in the UK, that dictates you can no longer sell devices with such weak authentication.

Another problem is that all of these forms of static credentials, whether they’re username, password or symmetric tokens — even if you were to change them or somehow have a way to change them dynamically — they are still not communicated across a TLS encrypted tunnel. In other words, if a bad guy can listen on the wire, they’re going to be able to pick up those shared secrets in clear text.

The beautiful thing about X.509 certificates we are in the business of selling is they use asymmetric encryption, so decryption keys are never passed on the wire in clear text. Even if the bad guys are able to steal the communication, even if the bad guy got that far in the attack, they still couldn’t decipher the communication. One of Icon Labs’ products, in particular, supports this very important concept— the ability to protect private keys. Their secure element integration libraries provide the ability to utilize a hardware secure element such as a Trusted Platform Module (TPM).

As you noted, the hackers are starting to focus, obviously, on more Internet-enabled device hardware. And suppliers are hardening their devices and the embedded firmware. But what about those large enterprises that are going to demand global capability. Europe is already looking at security certification as mandated. Root of trust and digital certificates aside, how likely do you feel like certification will be in the future on a global level?  But even if that does come about, who is certified? Is it the device manufacturer? The Internet network provider? The network operator?

Jason: Some groups are very good at this, such as Underwriters Laboratories (UL). Those are some of the world’s experts in certification, and they do have initiatives for IoT. I’ve talked to them and worked with them. Alan and I could sit here and rhyme off a bunch of these that we know, and some of these that we’ve worked with and are trying to influence. They’re all very well-meaning. I think they all have their place.

The problem is there’s no such thing as just one thing. There is no such thing as one Internet of Things. That’s one of the problems with that term. It makes it sounds like it’s just one concept when, in reality, IoT’s been around 30 + years. The diversity of implementations in the world is so vast that there can never be one standard that’ll cover even a small percentage of all the different use cases, and you’re also going to have a very verticalized view of the world.

In other words, the automotive market is going to have all of their own, as will the energy market, and healthcare has their own paranoid world. Even within those verticals, there is vast differentiation in the use cases for connected devices. Does that mean that there can be one body? I don’t think that’ll ever happen.

We can rhyme off all the acronyms, MQTT, CoAP, and many other standards and protocols. Those have only started to collapse on themselves recently. But we’re finding that they’re not collapsing to the point where there’s only going to be one or two winners. There’s probably going to be hundreds of winners that all have their niche place that are perfect for specific use cases.

Let’s take that analogy all the way to certifications. Unfortunately, I think Bruce Schneier is right in saying that we probably are going to end up in a world where there’s going to be legislation forcing basic security. In other words, the legislation we’ve seen passed in California, the stuff we just saw proposed in England, as well as in the state of Texas, are basically a direct response to the Mirai botnet, which is only step one. Most of these legislations are not going to be technologically prescriptive. They’re not going to name PKI quite often.

However, the current proposed US federal legislation is looking at NIST, actually giving guidance on identity management for IoT devices. That’s their wink and a nod to say that they won’t come out and name PKI, but they’re going to write the legislation in such a way where only PKI will be able to fulfill the mandate of that legislation. That’s coming. I’m confident it won’t cover all types or classes of devices because not all devices will need that level of security.

If you take a look at any of the significant consortiums today such as the Open Connectivity Foundation or OCS, one of the things you’ll find is that we are the co-root of their PKI infrastructure. In other words, if you want to be a member of that consortium, your certificate comes from us. That’s an enormous stamp of approval from those major IoT consortiums.

It’s part of the really good news story around IoT. That’s what’s going to get us away from the Mirai botnet. That’s what’s going to get us towards a more secure world where we achieve interoperability through the work of consortiums deciding upon either a single root or a co-root for their PKI infrastructure for the certificate issuance. All of a sudden, you’re going to start seeing devices soon that are finally secure by design. That’s a world that we want to be part of.

Alan: Despite the fact there is such a vast disparity between the types of devices in terms of the vertical markets, the capabilities of the devices, the interfaces, and therefore the attack vectors, there are still a set of best practices for security that can be applied relatively broadly across those devices.

What Icon Labs set out to do when we started developing what is now our IoT security solutions was to take those best practices and implement solutions in a way that was very scalable and could be ported broadly across a wide range of IoT devices. The concepts that were already implemented on servers, desktop PCs, and other high-end devices can be applied to custom implementations for IoT devices. So, people that were running these low-power, low-resource devices could still have strong authentication using certificates, could utilize TLS, could have a secure boot implementation, and so on.

 

In part 2 of this interview, Alan and Jason explain IoT security platforms, purpose-built IoT issuance, and their take on the unique security challenges facing the industrial IoT market, as well as other verticals.

 

_____________________________________________________________________________________

Alan Grau is the VP of IoT, Embedded Solutions IoT at Sectigo. Alan joined Sectigo in May 2019 as part of the company’s acquisition of Icon Labs, a leading provider of security software for IoT and embedded devices, where he was CTO and co-founder, as well as the architect of Icon Labs’ award-winning Floodgate Firewall. He is a frequent industry speaker and blogger and holds multiple patents related to telecommunication and security. Prior to founding Icon Labs, he worked for AT&T Bell Labs and Motorola.  Alan has an MS in computer science from Northwestern University.

Jason Soroko is CTO of IoT at Sectigo. Adept in solving business problems by synthesizing security with real-world operational needs, Soroko contributes to strategy, intellectual property development and consortium standards that advance private trust certificate management across industries. Prior to Sectigo, Soroko served in senior cybersecurity roles at Entrust, including Head of Malware Research, where he continually analyzed the cyber threat landscape and developed product strategy. He is also a frequent industry speaker, blogger, contributor to IoT Agenda and IoT for All publications, and co-host of the popular PKI and security podcast “Root Causes.”