 Okay, folks, we'll get started on the next talk. We have a talk by Joel Wittenauer on the future of security in open silicon. Okay. Good morning, everyone. Again, as James said, my name is Joel Wittenauer. I am the embedded software architect at Rambos Cryptography Research. The talk is only allotted 40 minutes, and I've got a lot of content. And I want time at the end for questions, so I'm just going to jump right in. So this is my agenda here, which is just to give you a little bit of background in who Rambos Cryptography Research is. We'll talk a little bit about Spectre Meltdown in foreshadow. We won't talk a lot about it, but because I think everyone's already familiar. And then I'm going to give an introduction into our crypto manager, Root of Trust core. We'll talk a little bit about the CMRT hardware and software stack. And then we'll finish the talk up to talk a little bit about how all of this can apply to Linux and how Rambos Cryptography Research is looking for some insight from the Linux security community in general to give us some feedback on how this could be used in your particular ecosystems. So first, how many here by show of hands have ever heard of Rambos? So quite a few of you. How many of you know that Rambos has a security division? Not very many. So Rambos purchased Cryptography Research in 2011, and that was the establishment of the security division. Cryptography Research was founded by a fellow by the name of Paul Cotcher. Some of you may be familiar with Paul. Paul was one of the guys who helped design SSLv3. In addition to that, Paul wrote the foundational white papers on side channel attacks for hardware for extracting secret keys, particularly DPA, differential power analysis. That was where Cryptography Research made their name, was in DPA, extracting keys from smart cards. I think at one time every smart card that was being manufactured, Paul could extract keys from one time about 20 years ago. Today Rambos Cryptography Research still has a strong portfolio in DPA protection. We offer cores. We offer software libraries with DPA resistance. We have an evaluation lab that will evaluate your products. We also have a workstation that you can use to evaluate your own products. On top of our DPA portfolio, we also have pay TV solutions and hardware. We have anti-counterfeiting solutions. We also have a mobile payments group in Rotterdam, Netherlands. We have a mobile ticketing group in East Kilbride, Scotland. We also have offices in Espo, Finland, in addition to our offices in California. We actually have a rather large security group that's spread across the globe, and very few people actually know about it. That's one of the reasons why we're here, is to introduce ourselves again, and I believe this is the first talk that anybody at Rambos has ever given at a conference quite like this. Anyway, let's talk a little bit about Specter, Meltdown and Foreshadow. I'm not going to talk much on this slide. I think everybody here knows what the particulars are in this room. If you don't, I have the related CVEs listed below. In addition to that, if you Google any of these, you'll find the respective websites that have the white papers that describe them. The one thing that I will note is that the Specter research team included my former boss, Paul Cotcher, who was the CRI founder, and my current colleague, Mike Hamburg, both of whom were on the Specter team. I believe Paul also contributed a bit to the Meltdown team. So this is really what is the money quote, I think, that comes from the Specter Meltdown and now Foreshadow, actually had to adapt my talk because Foreshadow was so recent. Beyond short-term solutions such as patching, the semiconductor industry should seriously consider designing chips that run sensitive cryptographic functions in a physically separate, secure core, solid away from the CPU. This design approach will go a long way in helping prevent vulnerabilities that can be exploited by Meltdown and Specter. And that quote is from Mike Hamburg, who is, again, one of our security researchers that worked on the Meltdown, rather Specter. So we think that Specter Meltdown and Foreshadow are just the tip of the iceberg in regards to micro-architectural flaws, again flaws that are specifically related to optimizations like the vulnerabilities that were exposed by Specter Meltdown and Foreshadow. You know, scary things are that we can break down kernel user memory isolation, virtualization, isolation. Foreshadow even attacks SGX, which is under Specter Meltdown, we thought that SGX was still okay. Foreshadow comes along and says no. So we expect that in the future there will be more bugs like this that will be found, again, as scrutiny around micro-architectures increases. So let's talk a little bit about what Rambus Cryptography Research's solution to this, and this goes, again, back to Mike's maybe somewhat self-serving quote, is our crypto-manager root of trust. So as you see here, on your right-hand side, you have what is like a die-shot. And in there you have the general processing region, which is where your CPU cores would be located. Executing Linux, Android, or any other high-level operating system. Next to that, connected over an internal bus is the secure processing core, which is, in this particular instance, our crypto-manager root of trust. The crypto-manager root of trust contains a custom RISC-5 CPU that was developed by Rambus. Secure memories that include a dedicated SRAM and dedicated non-volatile memory. Crypto accelerators, and the nice thing is it gives you the flexibility to run custom secure applications inside the CMRT boundary. So you can develop applications yourself and run inside our secure boundary using the resources available inside the CMRT boundary. The CMRT also offers strong hardware and for security, which includes anti-tamper features and other secure logic beyond what's shown here. Some of the use cases that we've identified are listed here. The ones we think that are most applicable to Linux are secure data storage, secure key storage, authentication, attestation, user data privacy, secure boot, and cryptographic acceleration. I think all of these are applications that would fit well inside the Linux ecosystem. So before I go on any further, since we are again here at a Linux security conference, there's some potentially confusing terminology that's used with the CMRT. So I just want to make sure I pin that down now because these are terms that I'm going to be using over and over again throughout the rest of the talk. And again, that could be confusing if we don't explicitly call them out. The first is what is a root with respect to the CMRT? A root is not a user. It's not a certificate authority in the world of the CMRT. A root is an entity that is composed of an ID and a permission set for access to CMRT assets. The root defines the security context in which user applications execute. And for a given CMRT, there can be more than one root that is installed. Again, that seems confusing from a Linux context, but we're not talking about a Linux context. We're talking about the CMRT's context. So it allows for what we consider a call multiple roots. So again, I apologize for that terminology, but that is what we use. And that is how we market it. Next is the term container. Again, in this particular instance, a container is not related to Docker or other OS level virtualization systems. In the context of the CMRT, the container is a secure user privilege application. Not the environment in which the application executes, but the application itself. And it's the application that runs under the context of a root that I described in the previous bullet up above. So what's the lesson here with this terminology? The lesson is you don't let hardware engineers name things. So when I got a hold of it, the names were there and they stuck, and we had to live with it. And there's going to be a lot more. These are topics that I'm going to bring up the rest of the way through this discussion. So the next topic on the agenda here is to go into the CMRT hardware. I think this is probably the most hardware specific talk that we've seen up till now. But I think without discussing and describing the hardware and our design methodologies at Cryptography Research where we try to build this onion of security from the ground up. So we start with layers of security at the hardware. And eventually when we talk about the software, we'll talk about the layers of security that we have inside the software so that we have defense in depth just like everybody else talks about. It's our design philosophy. It's something that we truly believe in, something that's actually worked well for us in the past. So we'll again start talking about the CMRT hardware and then move into software. So hopefully you can see how it builds upon itself. So what you see over here is a block diagram. It's a very simplified block diagram of the CMRT. So it doesn't have all of the blocks, but what I did was I called out the things that I thought were most important in the context of this particular talk. So what you see here highlighted are two blocks, the CPU and the memory protection unit, or MPU. Again, the CPU is a custom CPU designed by Rambus and it's specifically designed for the Cryptomanager route of trust. It's based on the open source risk five instruction set architecture and selected standard extensions of that specification. And what's critical about that is that our CPU uses standard tools. You can download the risk five GCC tool set and build code immediately that will run on our platform. So we are compliant with the risk five instruction set architecture, but it has cryptography research additional behaviors that are added in to, because fundamentally, we begin with designing for security, right? Note that our CPU supports the three privilege levels that exist for risk five, machine, supervisor, and user, and that will be important later when we talk about the software stack. We have a memory protection unit. It's based loosely on the risk five MPU specification, but it's tailored specifically again for the CMRT. We have 24 MPU regions that we can set up. Each MPU region is assigned a privilege level. You can't and a access type either read, write, or execute. The MPU registers can be locked until the next CMRT reset, and why that is important is that when we load machine or supervisor code into RAM, that code should not change throughout that entire boot, and so there's no reason for those regions to either expand or decrease in their size, and they should never change in their access type either. So we lock those in, and nothing, not even machine code, nothing of hardware can modify those registers until you reset, and so that gives us some pretty decent security properties there, I believe. The next important piece to the hardware story is that we have one-time programmable non-volatile memory that is private to the CMRT, writes of zero to one in our sense are permanent, meaning that you cannot go back and rewrite things from a one back to a zero. The OTP stores CMRT configuration that includes things like the device ID, the current life cycle of the CMRT, and a device unique key is also stored inside the OTP. One thing to note about the device unique key, it is never exposed on the CPU bus. It cannot be read directly by the CPU. It's never read by the CPU. As a matter of fact, when it's created, it's created through a back channel, through a command to the OTP management core during manufacturing personalization, so it's not injected by the CPU. It's done completely in the back, through a back channel. A table of root IDs and permissions, so if you remember back earlier, we were talking terminology, we talked about these root IDs and permissions. Those are stored in a table in OTP. In addition to those items that are stored in OTP, we also have general purpose non-volatile memory that's available to user containers or user applications, again containers or applications. The access to ranges of the OTP can be restricted by the permissions that are associated to the root. If you saw earlier, each root has permissions. Part of those permissions can restrict access to the general purpose non-volatile memory. You can either give some or all or none permissions to non-volatile memory for a given container associated with a given root. We'll get into more about how that works a little bit later. The first really important part of this are the crypto engines. From our standard offering, we have an AES engine, a SHA-2 engine, and a public key engine, or PKE. The AES core, we have multiple versions available, so as I earlier mentioned, we have differential power analysis resistant cores. We have an AES offering that has DPA resistance. We also have an offering that doesn't, depending on what your size, obviously when we do DPA resistance, the size and gate count increases. Similarly, we have a DPA resistant hash core. Same thing with the AES core, it only increases its size when you have DPA resistance. The public key engine is DPA resistant out the door. The key sizes will be support for AES, or 128 and 256 bits. We don't have enough people who ask for 192 bit, although I guess we could if asked. We have direct hardware support for ECB, CBC, CFB, counter mode, Galois, and I think a few others on top of this. The SHA-2 supports 224, 256, 384, 512. The public key engine supports RSA standard and RSA Chinese Render Theorem for 1, 2, 3, or 4K sized keys. We also support ECDH, ECDSA for the NIST curves like P256, 384, 521. The ED25519 and other curves are also available with the PKE engine. The next core, another really important one is the key derivation core. It's responsible for deriving and managing keys. It uses a NIST compliant key derivation algorithm to derive volatile keys from base keys. If you remember earlier I mentioned in the OTP we store a device unique key in OTP which is not exposed to the CPU. That key can be delivered securely again without the CPU seeing it directly to the KDC, the key derivation core, and you can use that to generate volatile keys, the same key over and over again, but it's volatile in that you don't store it anyway. I think actually a really good property is you don't have to store these keys anywhere. You have one base key that is stored in secure OTP. You can generate these keys on the fly, it's the same key every time. The other thing that's nice is that the part of the key derivation path where you derive the key is dependent upon what root, the security context under which you're running. One root cannot create the same keys as another root except for collisions which are pretty rare. That's actually where the security context comes from is that one root can create an entire fleet of keys and another root can create another fleet of keys and the two shall never meet, which is really nice. It's a great property. Again it operates independent of the CPU and can deliver keys to the hardware core so if you want to create a key and deliver it directly to the AES engine, that's supported. Similarly for the hash core, you can deliver keys directly to the hash core to do HMAC operations. Other important cores that I think are interesting, even specifically for your ecosystem are the key transport core which manages key interfaces outside the CMRT boundary. So you can use the key derivation core and your device unique base key to create a key and then you can export that key to another hardware block that you have. So if you have a proprietary hardware block that does some particular crypto function, if you want us to manage that key and deliver that key to that crypto block, that's totally supported through this key transport core. We have a NIST compliant TRNG and DRBG. That actually should be DRBG, I apologize. And then we also have a DMA controller that allows for fast movement of bulk data to and from SRAM, our internal SRAM, crypto cores, external memory, etc. So that gives you some extra speed boost for doing some of these algorithms. Okay, so the next topic is CMRT software. So hopefully you saw from the previous slides when we talked about the hardware where we kind of from the ground the CPU and NPU, we try and build up the security of the system, secure nonvolta memory. We're trying to do the same thing with the software stack as well where we start from the ground up, build security from the ground up. So the software stack, so what you see over here is a simplified diagram of the software stack, what components are available. And again, we have support for three privilege levels of execution and we utilize all three, not only during boot but also during runtime, we utilize all three. So in user space, obviously the containers are executing in user space. In Supervisor, we have an operating system, we use the Zephyr operating system and we also have related hardware drivers that are inside the Supervisor privilege. And then in Machine, we have our most security sensitive code that executes the machine privilege and we also have our internal secure boot. So the code that is responsible for securely booting the CMRT is located in machine privilege as well. So the first component to call out here that's located in the machine privilege is our first stage boot loader. It's located in read-only memory, so it's immutable. It begins the secure boot of our CMRT. Since the first stage boot loader is immutable, a chain of trust is built from that read-only memory through images that we have stored in OTP and in Flash. The image that we have stored in OTP is primarily to augment the behavior of the first stage boot loader, which is, again, in ROM, which is typically not built for a particular platform. Any platform-specific extensions are just put into OTP and, again, augment the behavior of the first stage boot loader. Again, since it's in OTP, it's effectively immutable. So in addition to that, to note here, we have a subset of the systems device drivers that are included with the boot loader. So, for instance, if we have to check a ECDSA signature of an image that we're loading from some external Flash resource into our RAM, we need a hash core to do the SHA-256 hash, and if it's a PKE, a P256 ECDSA signature, then we need our PKE there available as well. So we have, again, a subset of the device drivers that are in the machine privilege as well. So it's funny how I ribbed the hardware engineers about naming things. Well, we have something called a security monitor in our software stack, which I believe the Microsoft folks have in there. Is there a Sphere ecosystem as well? Our security monitor operates in the machine privilege, and that's where our most security-sensitive code is stored, and it's stored typically in a trusted Flash image that flashes external to the CMRT. So we will load that image into our RAM at runtime, verify its signature, and then allow it to do its work. So just to give you an idea of one of the operations that the security monitor manages for us is that when a user container is loaded by the CMRT and the supervisor actually manages the loading for us, then the supervisor makes a request up to the security monitor to verify one, what root context under which will this container actually execute. And we'll get into how that's managed here shortly, but it doesn't look up into the OTP to verify that this container actually belongs inside this particular CMRT. Next, it verifies the digital signature of the container code, hashes the code, and then verifies that signature using the PKE. It verifies the permission, so each container can request certain permissions. Those permissions, though, must be a subset or less than or equal to the permissions that are stored in the OTP table for that particular root, and then it applies hardware permissions to respective cores. So software doesn't actually manage most of the permissions. We do have some software permissions, but most of the permissions are actually managed by hardware themselves. So if you remember earlier when I mentioned that you can restrict address access to OTP, that's actually managed by the OTP management controller itself, not by software. We load in what address ranges are acceptable, what fixed areas such as life cycle, does this container have access to life cycle, does this container have access to device ID. Those kinds of things are all part of the permissions model and hardware enforced permissions, not software enforced permissions. And that's an important point to make here. The other thing that the security monitor does is it also handles root management. What that means is if in the field you want to create a new root for some other application to be able to execute inside the CMRT, if the container that's executing actually has permissions to do so, you can create that new root and add another root to the OTP table. If you want to delete a root, you actually can't delete it because it's an OTP, you can obliterate that root by effectively just writing all of the zeros to ones and that root is then invalidated at that point. And that code is then, again, as I said, managed here in the security monitor. So at the supervisor operating system layer where we have a modified version of the Zephyr operating system, it supports application loading. So we have the operating system, which is effectively in SRAM. You can load at runtime, you can request a loading of a container at runtime, which is our application. So we have a runtime application loader that's available, that's a part of the supervisor image. We have complete kernel user memory separation, which wasn't available on RISC-5 when we started this project. I'm not sure if it's available yet on the main line. We have a Unix Linux-like device-driver interface with open, close, iOctol. Now all of our modifications are controlled by Kconfig and most of these will eventually be upstreamed. I'm not sure what the timetable is for our upstreaming, but you can talk to us later about our plans for that. The other features of the operating system are that it provides a containers access to hardware cores, so user containers have no access to hardware. They're effectively sandboxed in a way that they do not have access to any hardware at all, and all access must go through these device-driver interfaces. So again, you use open, close, and iOctol to get access to, if you want to do AES, you have to open up an instance to the AES device-driver and then you use iOctol, Read, Write, and other system calls effectively to gain access to the AES hardware. The other thing is the operating system here is also the first line of permissions enforcement. So on the previous slide I mentioned that hardware is our backstop for all permissions enforcement, but we also do checks here. If you're really not allowed to access a particular region of OTP, for example, we'll stop you here, but if for some reason that check fails, we always have the hardware as a backstop. So we do it here, and then we also do it in the hardware as well. The last bit of the software stack here are the containers. Again, our containers are customer-developed applications. So they would be developed by anyone here in this room who's capable of writing a C program. It's just a straight C. We have libraries that are mentioned here that are available as well to help in development of these applications. Each container is signed with a private key that is associated with a specific root. On the next slide I'll get into the details of how containers are actually built and created, but just know that they have to be signed and that the key that is used to sign it is actually somehow attached to a specific root. Again, that root must be found inside the OTP table. Containers have associated permissions that control access to keys and hardware resources. Permissions are also limited in hardware to those available to the root associated with the container. So again, you have root permissions and then you have container permissions. The container has a subset of its root. It has a subset of permissions for its particular root. If, for example, if it requests an area of OTP that is not associated with its root, so its root does not have permissions to access that area, that container will be rejected. It's actually rejected and we wipe it out of SRAM. You're not allowed to request assets that your root does not have. And then finally we have the libraries here that are attached to the container. We have a C runtime, it gives you your mem copy, memset. And we also have a global platform TE compliant crypto library. So as I mentioned earlier, if you want to get access to the AES hardware, you can do the open and then the IO controls, etc. Before we do all of that work for you, we wrap those in a, again, a GPTE compliant crypto library that's available to developers who are writing container applications. So this is a very busy diagram. It's going to get busier here. But the first thing is, well, where does all of this come from? I mean, where do root permissions come from? How do you associate those things? So typically root permissions start with the SOC manufacturer. So the CMRT is embedded in a system on a chip. That system on a chip manufacturer probably created a root during manufacturing and sets up the initial permissions. If you have an agreement with that SOC manufacturer, they may also program your root with your associated permissions. Your associated permissions are probably something that you would work with the SOC manufacturer. And if you're the SOC manufacturer, of course, you can do whatever you want. So that's where the root permissions come from. It's just a file that describes what access this particular root will have. And any container that runs in the context of this root will adopt those permissions as well or a subset of those permissions. So how do we get this into the part? And how do we create this association? So we have down here a hardware security module that has a public and private key inside of it. And remember I mentioned earlier that a private key is used to sign container images. Well, what do you do with the public key? Well, the public key you export from the HSM. You calculate the SHA-256 fingerprint or hash digest of that public key. You attach that to the permissions and program it to the OTP. And that's how a root is founded inside the CMRT. Again, this typically occurs during manufacturing personalization. As I mentioned earlier, if you have a container that has the proper permissions, that containers later in life can also create new roots and program those roots through the exact same process. So how do you build a container? Well, again, it's just, it's C code. So and you just use a RISC-5 compiler to compile that into a binary where your text and data is located here on the right-hand side of the diagram here. So you have just your raw binary sitting here. You take the root's permissions and then you determine as the developer, the developer can create a subset of these. I'll just take the root permissions and program them. That's not really good design. You should be using the principle of least privilege to set your container permissions to what this code is actually doing. So if you don't need access to OTP, then you should say in here, no access to OTP. So you build your container binary. You attach to it a container ID and the request of permissions that you did through here. We take this entire object, send it over to our hardware security module, we hash it, we sign it with this private key, and then we attach the signature, the resulting signature here, and this public key to create the entire container image. So the container image again has the binary, an ID, the request of permissions, a signature of everything above here, and we attach the public key to the image. And now that is a container image. So now what do you do? I don't know. Let's see. So now you can load this entire image into the SRAM of the CMRT. We have mechanisms that facilitate that process. So you load this into SRAM and at this point, as I mentioned earlier, the security monitor first determines if this container's public key matches an existing root. So again, we just do a shot 256 of this, what's attached to this blob here. We take the shot 256 of this object here. We look in the OTP. Does it match any ID, any resulting ID? If not, we kick the thing out. If it does, then we go further. So the next step is now we're going to do the hash shot 256 of this information here. We're going to use this public key, the signature, and the hash of this information. We'll validate that signature. If that's good, we go on to the next. We evaluate the permissions, the requested permissions. We've now validated that they were signed by a trusted entity, right? So now we can check to see are the requested permissions within the bounds of this root, again, which is, again, stored in OTP. So remember, we programmed this information into OTP. We check to see if it's within bounds. If it's outside the bounds of the requested permissions, we kick it out. If it's inside the bounds, we're going to then apply those permissions to the respective hardware cores. And now your container can execute. Again, if your container requests to do something at runtime that's outside its requested permissions, or, obviously, the root's permissions, again, it gets kicked out. So I just wanted to have a slide in here to talk a little bit about why did we select the Zephyr operating system as the microkernel that we use inside the CMRT. The first and most important thing, because if it didn't exist, it wouldn't have even been part of our selection process. We had several microkernels that we looked at. It had an existing RISC-5 port. If a microkernel didn't have an existing RISC-5 port, we really didn't look at it. The other thing is that it is a Linux Foundation project. I'm not trying to kiss, re-render anything like that, but it does include a formal governing board, technical steering committee, and a security committee. All of those things actually were really important to us as part of the selection criteria. The other thing is that the Zephyr ecosystem is actually quite nice. We were quite impressed by the large active number of contributors, proper quality assurance, and CI were already in place at the time of us selecting Zephyr. There were great community guidelines and contribution reviews as things were being pulled in. One thing to note is a side benefit of using Zephyr is that all of our software is built using the flexible Zephyr build system. Our bootloaders, the security monitor image, our operating system kernel, and all containers are actually built using the Zephyr build system. This was actually a huge time-saver by us selecting Zephyr. I highly recommend if you're looking for a microkernel, look closely at Zephyr. Why are you all here? It's about Linux applications. On all the previous slides, I have been talking about a robust general-purpose, programmable, secure processing environment. The CMRT can be integrated into your platform's SoC, but once that's there and once it's integrated into your SoC, what do you do with it? Where do you go with it? The following slides are an attempt to answer this question, but really what this is is we're Rambus, Rambus Cryptography Research. We're looking from input from the Linux security community at large. Any applications or anything that you could see for using the CMRT, we're looking for feedback from you because we're presenting this as our offering to help solve a lot of problems in security in the wild today. But we want some feedback from you folks to try and figure out what we can do further with this. The first thing to note is we have a CMRT Linux software development kit. The SDK provides a full container development environment. We have an out-of-tree reference kernel module implementation. I'll talk a little bit more about that in the next slide. We have the RISC 5GCC7 suite that is part of our SDK. And we have a QMU emulator for fast container development. It enables development prior to the hardware being available. It's easier to use in debug than FPGAs in general. And the other thing is it's easier to scale your continuous integration environment rather than having a farm of FPGAs that are running your containers that you developed. You can have just a whole bunch of cores running QMU and executing your containers and getting test results off of that. So that's another great... Actually, we use that ourselves. We use the QMU environment ourselves for a substantial amount of our CEI. We also have FPGAs that do a lot of work too. We have a reference implementation available on the Xilinx Zinc 7000 evaluation board. And we have a Linux image that runs on the Xilinx Zinc 7000. And then you instantiate the CMRT and the FPGA fabric. And from there, you can begin testing out your containers that you've developed from there. So some notes about the CMRT device driver that we have. We have a reference Linux device driver which loads and unloads trusted containers for you. It provides an interface for user space applications to reach the CMRT. So basically the applications that you have using this reference driver is only limited by your imagination. You can pretty much do anything that you want with it. But you also have to make sure that you have available CMRT SRAM for your container that executes. But one thing to note is that we have mechanisms available to chain CMRT containers together to get around these CMRT. So you can have a computation stored away securely so that another container later can pick it up and begin using it to chain things together. We have that available. So here are other things that we're actually actively looking into doing with the CMRT. And we're also gauging again if there's any interest in this is creating a Linux crypto engine module which would be similar to the examples that you find on the Linux tree at Drivers Crypto. It requires a general purpose crypto container with a compliant interface that would plug in underneath there. Another thing that we're actively looking into right now is trusted platform module emulation either 1.2 or 2.0. Which again would be similar to the examples that you find in Drivers Char TPM. It reduces the need for an extra part on the PCB. So I think this actually excites me more than anything is that if we could reduce and get rid of a part on the PCB and traces on the PCB and alleviate that area and move it into the SOC inside our core, I think that's actually an interesting use case. Again it requires a container that exposes the TPM interface and again these are things that we're looking at but we're looking for feedback from you folks to see whether or not these are things that would actually excite your interest to you or interest to you enough to integrate the CMRT on your particular platform. Okay, I don't know if I have any time left or not. Out of time? Okay. So if you have any questions, one question. Thanks for your talk. So you provide the hardware solution and do you have defenses against physical attacks like various kinds of glitches and so on? Yes, actually. And we can talk about that after. It's pretty involved. And if in my cell this is interested we can talk. And a small question. Does your board provide GTEC interface? Yes. And do you provide it in your production? Yes. And you can also disable the JTAG as well. And then securely re-enable it later. Okay. Thank you. Any other questions? Here's my contact information. And I really appreciate the opportunity to talk here. Thank you all very much. Thanks, Charles.