Milan Lazich: Welcome to today’s podcast. My name is Milan Lazich with Intrinsic ID and I’m speaking with Pim Tuyls, Intrinsic ID’s CEO, and we’ll be talking today about the upcoming RSA Conference. How are you today, Pim?
Pim Tuyls: Hi Milan, thanks, I’m doing very well.
Milan Lazich: Well, I know that there are two key use cases that will be highlighted in the Intrinsic ID booth at RSA. One is device-to-cloud security and the other is a trust anchor on FPGAs. Let’s start out with securing cloud connectivity. Can you tell us a little bit, a little bit of background on the key considerations that need to be addressed for that?
Pim Tuyls: So cloud connectivity in this case is about a typical IoT scenario where devices are going to be connected to one or more clouds. And the device will typically have a sensor on board, sense information about the environment, and send to the cloud for different kind of purposes. So in the cloud an algorithm will run that extracts information about the data, from the data that it got, and use those to offer recommendations or give … analyze trends and these type of things. Now, this is, of course, very valuable if you can do that in the right way, and we see that already in many of the recommend systems that are being used those days. But one needs to make sure that the data that is sent to the cloud is of course trustworthy. It is the correct data that has not been tampered with. That this data comes from the correct device that one thinks it comes from such that the analysis that you do, the recommendation that you make, is a good recommendation, and is also a trustworthy recommendation.
Milan Lazich: So with more and more data being transmitted from device to device, obviously the concern over keeping it secure is, growing commensurately.
Pim Tuyls: No, absolutely. And the security is mainly an authenticity problem. So often not so much the exact content is that important – that can be the case too, of course. But the main thing that is important is its authenticity. That means making sure that the data has not been changed on the way to the cloud and is indeed coming from the device one assumes it is coming from.
Milan Lazich: Very good. Can you give us some detail, then, about what Intrinsic ID will be showing during RSA about device-to-cloud secure connectivity?
Pim Tuyls: What we will show, in fact, is a device that is built … that is a smart device built with a chip, and that chip in this case is an NXP chip, an LPC55S69, that is then connecting to the Amazon AWS cloud. And what we’re going to show is that in a software-only way, we can set up a very secure connection between the device and the chip and the cloud in such a way that all data being transferred, from the device to the AWS cloud is fully authenticated with very secure keys that cannot be, cannot be broken. So we will also show, in particular, the whole flow, like how easy that really is to do all the steps from enrolling the device, generating the CSR – the certificate signing request – and generating the certificate. And then also register the device and the certificate, with, in this case, the cloud provider being AWS. So it will be like a full-package solution that we show at the booth at RSA.
Milan Lazich: You mentioned a couple things that I think it might be helpful to drill down on. One is the fact that this is a software-based approach. Can you give a little bit more background as to why that approach and what the advantages are?
Pim Tuyls: That’s a very good question indeed, because that might sound a little bit contradictory. But it is a software approach, still making use of the hardware that is already present. So it is software that basically reads out the properties from the hardware, turns those into secret keys and use those secret keys to protect, basically, the whole TLS channel. And it means, the fact that you can do this with software, makes it also very flexible and very easy to use. You do not need to make any modifications to the hardware, you do not need to add any additional hardware, like a secure element, on the board. But you can keep it very nimble, very flexible. You can keep it low cost and low power – typical requirements for an environment like the Internet of Things. It also means that, in this case, the root keys are really coming from the device itself, which means nobody has influence on these root keys. Not a device maker, not Intrinsic ID, not the cloud provider. The root keys, the secure keys, are really only known by the device. And that’s exactly what you want from a secure scenario. So these two elements really make this a very elegant, low-cost and at the same time very secure solution that is tailored, really, for the Internet of Things.
Milan Lazich: And as you’ve been describing it, you like to think of this as an “EZ” approach, something that is easier to implement, I take it.
Pim Tuyls: Yes, exactly. Also an alternative approach, which I hinted to would be to have a separate, secure element, let’s say on the board. Which means additional hardware, additional board space, hardware-to-hardwire connection from the secure element to, let’s say, the microcontroller. That has to be tested. It means shelf life of, and logistics of, the secure elements being ordered. So all those things make a solution based on an additional secure element a fairly complex solution.
While a solution based on software is easy to implement and offers also, for instance, many maintenance advantages. Because over the whole spectrum of your devices, we can offer the same API, which means also that, in terms of maintenance, this becomes much easier and hence lower cost.
And finally, with a software approach. If you also want to change from one microcontroller driver to the other, that can be done in a much more easy manner than when you have a separate hardware element that you have to integrate with another type of microcontroller. So it is mainly that “easy” aspect that we also emphasize in our approach that security should, of course, deliver a very secure solution but at the same time a solution that is easy to implement because that also implies that less mistakes can and will be made.
Milan Lazich: Okay, so low cost, flexible, secure and easy. It sounds like a combination no one would argue with. Let’s turn to the other key use case that will be shown in the Intrinsic ID booth. That is a trust anchor on FPGAs. Can you give a little background as to why this is of particular importance and why this might be more difficult, might be a difficult challenge?
Pim Tuyls: Yeah, so FPGAs, of course well known and well suited, first of all, to many, many applications. Like in defense, in medical, automotive, data centers. More and more, you see that FPGAs offer a very good component, and it was part of the solution. Now, in many of those situations, also, the FPGAs have to carry out some, security functionality. And it turns out that often the user can not have access to secret keys to carry out the security functionality. So what we make possible here is that on basically any FPGA, we allow the user to install a trust anchor that can be used by the user itself to generate keys, to store keys and, hence, to encrypt and authenticate data and information being exchanged with that FPGA. And that is really crucial in currently the world that we live in, and certainly the world that FPGAs are used, to make sure that, again, the information is properly protected.
Milan Lazich: Now, FPGAs, what is different about their vulnerability that requires these special considerations?
Pim Tuyls: So the typical FPGAs, they don’t have onboard OTP or flash where keys can be securely stored. So that means that the keys you would have to store offsite of the FPGA, so in a separate memory. Which makes them very vulnerable, because of the point in time you would need the secrets they would have to be transferred to the FPGA, and during that transfer you could easily, very easily, snoop them. So by what we offer, again, the keys can be extracted from the physics of the FPGA, meaning that they’re only known by the FPGA, they’re on the device itself. They don’t have to be transferred to the FPGA. And in that way you can generate them securely. You can keep them securely and you can use them in a secure way.
Milan Lazich: So does this offer a particularly high level of security?
Pim Tuyls: Ah, yes. Indeed. The security level that we deliver with this is what you could call Defense-Grade Security. In fact, it is being used as we speak in defense space, and it will be used in many more defense systems, especially due to these properties that you extract the key from, from the physics of the device. We did not yet talk about it but it means, for instance, that when the device is turned off the keys are not present. So there is no key to find, there are no digital bits somewhere in the memory that represent a key. There is only the physics. Which makes it much, much harder to extract any information off those devices.
And typical things that they do with it is making sure that that device cannot be cloned. On a, let’s say ordinary, FPGA setting, if you buy an FPGA of the same type and you copy the bit stream of another, connect it to another FPGA, you have made a clone of the system. Because if the bit stream is the same, and the FPGA is the same, this system is basically the same. With the technology here that we offer we can make – the keys are really device specific. And that means that if you buy an FPGA of the same type, and you’re copying the bit stream, the bit stream will not work on the new device anymore, since the keys with which it is encrypted are specific to the original device, and therefore will not work on your device. So you really can create unclonability. That is, of course, important in defense, but also in many other spaces like medical market, where you see a lot of counterfeits. Also communication environments where you see more and more clones coming. In automotive, clearly, where you want to make sure that you’re working with the highest quality components. This topic of unclonability, and hence authenticity, is a very important one.
Milan Lazich: Well, thanks, Pim, appreciate the preview of what Intrinsic ID will be showing at RSA next week. Thank you very much for joining us.
Pim Tuyls: Thanks, Milan. It’s very nice to have this interview with you.
Milan Lazich: Very good. So we hope to see all of you at RSA in San Francisco the week of February 24th at Moscone Center. Thank you for listening, and we look forward to having you on our next podcast. This has been Milan Lazich with Intrinsic ID CEO Pim Tuyls. Thank you.