Security and the protection of privacy and personal information is growing in industry awareness, as more and more manufacturers recognize the need to implement fundamental security measures. Data and identity integrity and product security are critical aspects of the Cloud and IoT today, and must be properly and thoroughly addressed in order for further development and adoption of next-generation IoT devices.

We spoke to Alan Grau, the VP of IoT and Embedded Systems at Sectigo, about using purpose-built IoT security certificates from a trusted third-party certificate authority in August. We followed up with him to talk about the hardware side of the issue, as hardware implementation and chip-level security will be key to next-generation product designs.

ECD: The last time we talked, we talked about the software side. This time, let’s focus on the hardware side. When we're talking about security, it's going to have to be multi-layer and multilevel. But now it has to have a foundation at the hardware level at some point, to ensure complete security. What are your thoughts on that?
Grau: Oh absolutely. We've got plenty of history to show that the system has to be secure and the system is hardware and software, and they have to work together. If you don't have that hardware enablement, you won't have secure devices and secure systems. Having said that, a lot of companies are starting to offer secure blocks within their chips or some other hardware oriented security to enable proper authentication and trust. Where are we with that and how do you see it developing? 

A lot of people will refer to that as the “root of trust” and that can be implemented in hardware in a number of different ways. In some systems they are building a separate microprocessor that will run on the device, with your main core doing the normal processing things, and a second microprocessor called the secure element. There's a standard called a TPM or trusted platform module that people are using. So there's a number of systems like that. Others have the same type of capability but just in another core on the same SoC. 

Or you've got things like ARM's Trust Zone, where you have a single core, but it has some hardware enablement to logically divide that into a secure or trusted world and a normal world and perform those safety critical or security critical operations in that secure world. Companies are developing solutions and OEMs are starting to utilize those in their designs. If we look at PCs and smartphones, the TPM chip is a pretty standard element of any reasonably modern PC, and we're seeing more and more adoption of that same technology in IoT devices.

The TPM standard works well for PCs and phones that are relatively high end, and have a high bill of materials cost devices. A TPM chip might be a $1.50 or something like that. You're doing a dollar and two dollars or something in that rough ballpark, depending on volumes and vendor and all those things. It's a negligible cost in an iPhone or a new laptop, but if you're building a 50 cent sensor, that's obviously not something you could swallow. So some companies have developed some secure elements for the IoT space that are lower cost or reduced feature set or a more tailored feature set for use in the IoT space.

ECD: Could you walk us through the basic process of ensuring that a device is secure?
Grau: There's two main parts to that. There's managing the identity of the device, and then there's ensuring the integrity of the device. If we look first at the integrity piece, that's just ensuring that the device is running authentic firmware from the OEM or from a trusted party and that it hasn't been tampered with. That’s where we provide a secure solution, for example. Secure boot will be integrated with that hardware secure element, to ensure that the secure boot artifacts, as we call them, the things that we use to know that the device's firmware is authentic, that they haven't been tampered with.

That provides a secure place to store the validation keys and certificates, and to store the code signatures and things like that, so the secure boot process has data that we know can be trusted and it hasn't been tampered with. The other half, or the other major piece of it, is the device identity side. If you think about common access to a website, and before you make a purchase your browser validates the certificate served up by that site to make sure that it really is who they say they are, and not some website that a hacker's created that makes it look similar and they're going to get your credit card info. 

But that works because you've got a browser with a user interface that will pop up a warning. If you're ever on a website and your browser pops up a warning saying, "Hey, this website isn't trusted or the certificate isn't trusted," then you need to pay attention to that and not proceed. Maybe you're on a Wi-Fi network and somebody is doing a man in the middle attack, or there's something going on that shouldn't be.

But in the IoT world, you've got two devices and they need to authenticate each other. There is no human in the process. Also, the other part is you validate it's a given site through their certificate, they validate that it's you through your username and password that you enter, maybe with second factor authentication for other more secure systems. So that provides a level of trust that they can verify that you're really who you say you are, and not somebody logging into your accounting and doing things they shouldn't be. Online banking, for example. You typically would have second factor authentication enabled, to provide a higher level of protection.

In the IoT world, you're talking machines talking to each other, and you want to make sure that if an IoT device is talking to a web service or a cloud service or to another IOT device, that both devices want to make sure that the other one is really who it says it is, and certificates are used for that process. The primary business that Sectigo is in is issuing certificates. What we've done is we've enabled the ability to produce or to issue certificates for IoT devices. We need to be able to issue them in bulk at high volume of certificates. It's a different process, it's a different set of interfaces, and it's much more automated for issuing certificates for IoT devices.

You need to issue thousands, or hundreds of thousands, or even millions of certificates as opposed to what you would do for issuing certificates for website, public SSL certificates, where you're selling tickets to a company. It's a much more automated, much more scalable process. We've taken that technology that we have the heritage as a public CA with all that comes with that, and made that much more applicable to IoT devices, certificate issuance.

But where that ties back to a hardware point, and this is the part where I think companies really can start to build a strong level of security into their devices. When you generate a certificate, you have to have a key pair, a public key and a private key. As the name implies, that private key needs to be kept private or secret. If that gets stolen, then you lose the ability to securely communicate and securely use that certificate's ability to trust it. 

With the hardware secure elements, the TPM chip or other secure elements for IoT device, you can generate the key pair inside of that secure element, and then you can export the public key, which you use to go get the certificate. All the other information around that tells the identities. So like the driver's license, there's my picture on it, there's my address, all those other pieces. A certificate has all these other pieces wrapped around the key pair. But that private key remains hidden in that hardware secure element and it never leaves it, and if you need to do any crypto operations that use the private key, you send them to the crypto chip and let it do it there. 

That makes it much more difficult to discover or compromise that private key. In fact, it's proven to be extremely difficult to do so. There have been a few very sophisticated cyber attacks that have managed under certain circumstances to discover those keys. There was one recently called TPM-Fail that actually just came out, and the vendors that were affected by that have since patched their devices. But the interesting thing, and I'll go off on a little bit of a tangent here, is in the TPM world, we see a security breach and a patch every few years, it seems like. They're not frequent.

Whereas in the software world, companies are sending out monthly updates with security patches. It's this very, very frequent ongoing thing. The TPM-Fail attack was a side channel attack that looked over many, many, many iterations of requests, gradually discovering a few bits of the key, a few more bits of the key and eventually figured out what the private key was. Like any security measure, it's not perfectly safe, but they are highly secure and it very, very difficult to hack. 

ECD: That was very informative, thanks for taking the time to talk to us about this important subject.
Grau: The pleasure was mine.