NVIDIA Corporation (NVDA) Earnings Call Transcript & Summary

Hi, everyone. I'm Suhas Sheshadri, Product Manager for NVIDIA Jetson. Today, I'm joined by Larry O'Connell, VP of HR Solutions at SecEdge; and Mike Hendrick, VP of Engineering at SecEdge. Today's topic is quite important as it deals with security and protecting your platform from cybersecurity attacks. edge AI devices powered by Jetson are deployed at far edge, which means it is easily accessible and exposed to a range of cybersecurity attacks. Security becomes extremely important for anyone deploying edge AI and we at NVIDIA provide various security features on Jetson to protect your platform. We also have partners like SecEdge, who provides turnkey security solutions on Jetson. It's been more than 10 years from the first Jetson launch. And in these 10 years, not only we have brought these amazing lineup of Jetson devices, but also revolutionized the AI software stack at the edge. In parallel, constantly, we have also been given priority to security and brought security features to ensure your devices based on Jetson are protected. Jetsons are deployed in various use cases, ranging from AMR, retail analytics, smart city applications, robotics, medical and so on. And security is an important feature in each and every one of these use cases. On Jetson, we provide a variety of security features, including secure boot to ensure that you're booting off of a known and authenticated stack; trusted execution environment to ensure you can protect core and data from normal Linux world; secure storage for security storing your keys and certificates; disk encryption to encrypt data at rest; and memory encryption to encrypt data in memory. We also support security engine, which is a hardware accelerator to provide cryptographic acceleration. We also provide various countermeasures to protect your platform from physical attacks. Rollback protection is also included to ensure no one can rollback your software stack to previous versions, which may have known security vulnerabilities. Not only these, we are also bringing support for firmware TPM for device authentication and storage of cryptographic keys and certificates and also support for measured boot to ensure platform integrity. All these features we provide on Jetson can be enabled based on the security threat modeling. We understand not everyone is a security expert, analyzing the security threat models based on your deployed use cases with security feature to enable and how to enable them, it's not a simple task. For that, we have partnered with security experts like SecEdge on Jetson. SecEdge provides various turnkey security solutions on Jetson and integrates with security features on Jetson, which makes it easier for our customers to not only protect the platform at the edge, but enable security from edge to cloud. Now I'll hand it over to Larry from SecEdge to talk about why security is important and giving you a deep dive on security. Over to you, Larry.

Thanks, Suhas. Welcome, everybody. Thanks for having me. My name is Larry O'Connell. I manage our edge AI solution here at SecEdge. And today, I'll be walking you through our technology and our collaboration with NVIDIA, which we've combined to deliver a solution for security and AI model protection on the NVIDIA Jetson platform. Here are today's topics. First, we'll give an overview of SecEdge and our partnership with NVIDIA. Then we will go through edge AI security, why it's important and especially why now. Then we'll dive into device level. That's our SEC-TPM solution. We'll walk through the concept of the firmware TPM and other device security features and then how those features are enabled on the NVIDIA Jetson hardware and how they're integrated with the JetPack. Then methods for protecting AI models at the edge. Then we'll move on to secure connectivity, our [ sec VPN ] solution. This is the concept of protecting data has moved from the device back to its applications wherever they may be in the cloud or data centers. We'll cover AI model protection in transit and then the concept of multi-tenant security and application data security. Then we'll go through some additional links and tips on how to get started, and then we'll take some questions at the end. SecEdge is a leading software provider for digital security to the edge. We have solutions for the edge AI, IoT and data center markets. We have a complete chip-to-cloud solution, including a robust set of features and functions for device security, a trust provisioning service for enabling credentials on a device, AI model protection and management, secure connectivity from end to end and a suite of tools making it possible to rapidly test and deploy your security solution. SecEdge is NVIDIA's security partner for edge AI. We've been working with the Jetson team for a number of years. We have completely integrated our device security solution with the NVIDIA Jetson Orin and JetPack 6.0 that delivers a solution that covers secure boot all the way to edge AI model protection. We also collaborated with the NVIDIA team on the firmware TPM component of the solution that's now available as a component in JetPack 6.0, and it's a piece of our SEC-TPM turnkey solution, which includes the fTPM device security, AI model protection and trust provisioning. We're an active member of the NVIDIA Partner Network, and our solutions are supported by NVIDIA's amazing hardware partners. Examples are AAEON, Advantech and AVerMedia. We're here because edge AI security is more critical than ever. You may have heard that 3/4 of all data is expected to be processed at the edge. We are observing that edge AI deployments are accelerating. There is a number of exciting trends that are driving that. Next-generation hardware like the NVIDIA Jetson Orin, maturity of edge AI models and the methods to train those models and generative AI at the edge. That ultimately drives a new set of edge device security challenges. For example, the models are large. They're sometimes distributed between the edge and the cloud that creates a security model not necessarily in line with the conventional security models. Another example would be generated AI models that are trained with a specific universe of data, for example, a medical device, and that data is sensitive and it needs to be protected. That leads to a number of AI model threats, data corruption or poisoning, outright theft of a model and attacks on an increasingly exposed supply chain, and the consequences are severe. Not only are we dealing with lost data or intellectual property, there's also an increased liability for users or developers to be exposed to data they're not supposed to see. And all that leads to harm to reputation and brands and overall reluctance to deploy AI at the edge. Okay. Let's walk through edge AI security. And when we're talking about edge AI security, we mean chip to cloud and there are 3 key pieces that make up that solution. The first is device security. Verifying the device is authentic, verifying that the software on that device is safe and protecting that device from attacks. The second is AI model protection, that's protecting AI models on a device at the edge and protecting data in transit from that model to applications that manage it. The third is secure connectivity and management, and this is protecting any data stream that would go from an application to the edge device. Let's dive into the first piece, device security. We're going to talk about firmware TPMs, integration of device security features with the JetPack, AI model protection at the edge and secure software provisioning. The first component to discuss is a firmware trusted platform module or fTPM. And to discuss that, we first have to start with the concept of root of trust. A root of trust is a device component that is trusted and immutable and it performs critical security functions. It cannot be changed and is used ultimately to determine the most basic security functions on a device. A trusted platform module is a dedicated root-of-trust module that's used to secure a device. It does 3 things: It provides a unique device ID; it creates in stores encryption keys; and finally, it provides boot measurements that verifies that the software of that device is authentic. It is based on standards maintained by the trusted computing group or TCG. And TPMs can exist in a number of different flavors: the first is dedicated hardware, a chip or module on the device; the second is a firmware TPM, the functionality in firmware that is specified in TCG's TPM version 2.0; and finally, it can also be delivered by software anchored in the hardware in the SOC. As a result of our collaboration with NVIDIA, the fTPM is a component of our SEC-TPM turnkey device solution. SEC-TPM includes Trusted Computing Group 2.0 compliant firmware TPM, that's enclosed in the NVIDIA Jetson Orin's hardware secure execution environment. Along with that is a complete suite of device security features integrated with the NVIDIA JetPack. Also supported is the AI model protection methods on the Orin and it includes as well a post-assembly or field trust provisioning service. Okay. Before we move on to the rest of the device security features, let's talk about why this is so important that we have in fTPM versus a hardware or discrete TPM in the solution. The first and most important is that it is updatable. Encryption algorithms become obsolete. When that happens, devices deployed in the field are now at risk. With the firmware TPM, those encryption algorithms can be updated to secure the device. The second is performance. There is no longer a discrete chip in front of a powerful processor like the Jetson Orin that can hurt the performance. Microsoft did a study a few years ago and proved that performance increases between 2x and 15x depending on what's being run when you have a firmware TPM integrated in the powerful processor versus an external chip. And then finally, because that functionality is locked in the secure hardware enclosure, the solution is more secure. Lastly, you don't have to deal with the headache of managing an extra piece of hardware. You don't have to design it in, you don't have to maintain the parts, and you don't have to deal with the supply chain. Okay. Let's talk about how device security features are enabled on the Jetson Orin. First, let's talk about the architecture that's used to enable the features. The Jetson Orin uses a technology called Arm TrustZone that's on an ARM Cortex-A platform. And Arm TrustZone features a secure area and a rich area in the memory. And the rich area is where our rich OS operating system like Linux and the applications that would run on the Orin device would be housed. And a suite of APIs would then control the access between those applications in the rich area and the secure area. The secure area includes a secure OS called a trusted execution environment and the ability to deliver trusted applications to deliver all of the security functions and features you need to protect the device. So ultimately, in hardware, we get domain separation, secure memory, secured data, a trusted boot function and finally, the ability to run trusted applications. This is the basic foundation in hardware that is used to deliver security features and functions on the Jetson Orin. And here's how it is enabled on the NVIDIA Jetson Orin supporting TrustZone. Jetson Orin hardware supports the partitioned memory. And SecEdge has enabled a trusted execution environment, secure OS and a suite of trusted applications, encryption key and certificate management, storage and the fTPM, Linux. And the rich applications are running in the rich nonsecure area and a robust client API allows access between the applications and the OS and the trusted applications. This enables a complete suite of security features and functions, including secure boot, secure firmware updates, recovery in the event of a device failure, secure software provisioning, AI model protection and secure integration with cloud applications. This is the approach that is used to protect AI models at the edge. We have our NVIDIA Jetson Orin hardware supporting TrustZone. There is a rich or nonsecure environment, supporting Linux and a secure environment or secure enclave supporting a trusted execution environment or secure OS. The model is encrypted and locked in memory when it's at rest. A trusted application verifies permissions and decrypts the application. The trusted application then loads the Linux application and runs the model. After the model is run, it is removed from volatile memory. With this approach, the model is encrypted when it's at rest and only run with permissions from a trusted application. And now it's time to install software and deploy the device and that introduces us to the concept of trust provisioning. Trust provisioning, very simply, is the injection of credentials in a secure environment. That ensures that the device is authentic the first time it is run. The traditional discrete TPM method requires doing this at the manufacturing level and a secure facility. By moving to a software model, this can be done post assembly or in the field. The SEC-TPM trust provisioning service, in summary, creates a known safe software image independent of manufacturer that attests to the authenticity of the boot image and creates unique instances for each device that cannot be cloned. Here's the process high level. We start with an NVIDIA device. That device has a device firmware and it is designed with the SEC-TPM provisioning application. In manufacturing, boot components are provided to the SEC-TPM provisioning service, which then returns a signed encrypted boot image that is then flashed to the hardware during manufacturing. In the field, when it's time to activate the device, the device then authenticates with the SEC-TPM service and the device is ready to use. So the solution provides a number of benefits. The first is a clear alternative to using a hardware TPM chip, providing hardware-level security with improved performance and the ability to update in the field. Second, the solution is turnkey, the fTPM, device management, AI model protection and provisioning are all provided in a turnkey service. And also, the solution gives you a product that meets a host of industry regulations, including Microsoft Azure, secure course certification, the TCG specs and a number of government regulations. Now that we've secured the device, let's move on to secure connectivity, the sec VPN solution, and we will cover AI model protection in transit, protecting application data and finally, scaling the solution to an unlimited number of devices, users and applications. The key problem we're trying to solve here is the multi-tenant problem. Let's look at an example with video. It's going to be smart city or public safety, et cetera. This is a video camera running AI locally. And there are a number of entities that are exchanging data with this endpoint. The first is the AI model developer, which has an AI model deployed locally. This developer is going to be monitoring and maintaining and updating this model. The second is in ISV, who might be running software to manage and control the model. The third is an equipment vendor, the actual camera vendor who would be accessing the camera for updates. And then finally, the end user who is using those applications to actually read the video feeds and the inferences provided by the software. All of these entities require some kind of secure connection to not only allow them to access the device and maintain their own application, but also to protect themselves from any data that they do not want to see. We have a number of security objectives here, including protecting the AI models when they are in transit, when the data is in transit. Second is to provide secure access for any application in the solution and similarly provide access for secure updates for any application and secure management of the AI model. There are a number of challenges here. The first is to be able to handle the multi-tenant problem, and that means delivering data privacy between the tenants. The second is to separate data and control planes. The third is to provide secure remote management for any equipment or model updates. And then finally, do all this in a way that can scale to thousands of endpoints. So the policies we are implementing are not set up manually one at a time. The clear approach to take when solving this problem is IPsec VPN. VPN tunnels are critical for a solution like this. Let's walk through the key requirements of the solution and how we can address it with IPsec VPN. The first requirement is the separation of control and data points. The second is similarly, separate access for applications and users. The third is a private network connection. We want to keep that IP address hidden. The fourth, as we discussed, is to scale the solution to unlimited devices, tenants and applications. And then finally, persistence, meaning the connection is up for as long as you need it. IPsec VPN addresses all of these. The separate tunnels are provided for control and data planes, also separate tunnels provided for applications and users. IP addresses are hidden. We can provide an automatic enforcement of rules, credentials, encryption and policy, meaning we can scale. And then finally, IPsec VPN is connection-based, meaning the sessions are persistent. This compares with other methods like mTLS which is more transactionally designed, meaning you don't really address these issues. There is one channel sharing all of the data. The IP address is exposed, everything is set up manually and you are setting things up on a session basis. The connections are temporary, not persistent. So when it comes to solving this problem, IPsec VPN is really the way to go. Let's take a look at the end-to-end solution now with SEC-TPM. To review, we have secured the Orin device with SEC-TPM. And now it's time to apply the secure IPsec tunnels from the device back to the applications wherever they may be in a data center or on any cloud platform. This is sec VPN. The 3 components are MicroEdge, which initiates the IPsec session and then manages multiple encryption tunnels per device. You're going to have as many applications as you want coming out of the device. It is bound to root of trust, and it is integrated with NVIDIA Metropolis. Cloud edge terminates the IPsec tunnel. And then finally, control edge manages keys and handles key rotation, certificate management and other relevant security functions. I'd also like to introduce a product called SecEdge Studio. This is specifically designed to make it easy to rapidly set up test and deploy a solution like this. SecEdge Studio is a secure connectivity development test sandbox. It's available on Google Marketplace. And the idea is to automatically allow you to deploy your solution in a cloud environment with virtual machines running on the MicroEdge instances and the cloud edge instances, the two ends of the IPsec tunnel, so you can simulate your device application and your cloud application protected by an IPsec tunnel. And it's automatically set up through SEC-TPM, making the configuration enforcement of policy is really easy to do. And you can check this out and test and deploy in really a matter of weeks and not months. Okay. Let's summarize and let you know how to get started. SEC-TPM to summarize, is a turnkey solution, providing device security, AI model protection and device provisioning. You can contact us to try it out on your NVIDIA Orin device. sec VPN is a turnkey solution that provides secure scalable device to application connectivity, and you can simulate that deployment using SecEdge Studio. We also have the EmSPARK Security Suite, that's a collection of firmware tools and APIs for any custom builds you might want to do on your device outside of our turnkey solutions. And we would also encourage you to work with our partners, AAEON, Advantech and AVerMedia. If you'd like to learn more, you can check out the link to the SecEdge solution for NVIDIA on the SecEdge website. We also have a white paper for protecting AI at the edge. And if you need to get a hold of us, you can always contact us at [email protected]. You can also contact me directly or Abhijeet Rane, who runs our sales and business development. And with that, thanks, everyone, for listening. Thanks very much to our friends at NVIDIA for hosting this webinar. And now I'll be joined by my colleague, Mike Hendrick, our VP of Engineering, and we will take your questions.

Hi, everyone. Thanks for attending. I see a lot of questions. I hope we were answering the questions while the video was going through. I'll start going to pick up the questions one by one, and so we can answer it live as well. But keep the questions coming. We will answer as much as we can. Let's start. So Mike, what do you mean by measured boot? Would you be able to explain measured boot?

Yes, sure. So measured boot is typically -- it's part of the TCG spec. It is exactly [indiscernible]. But typically, it's taking the hashes of the mutable code in the boot process and signing those with the TPM credentials and having them in a log. So at any point, you can clear that log and see the software that was used during the boot process and make sure it matches the intended software, the intended software that was meant to be -- because this is [ nonchip ], it also has the security process. So it is a -- it's sort of a double check on the security process there.

And just I'll ask the question by myself. I'll just try to extend this particular question. Measured boot and TPM, are they -- measured boot depends on the TPM, Mike?

The measured boot is defined by TCG, very specifically. So that's where you often hear measured boot is with the TPM. But really, it just means taking some kind of like hash of the code so that you have -- the measurement is basically the hash of the code so that you can verify the specific code that was loaded matches what you expect it to be. So the measurement is the hash.

Thank you. So the hash is the same in the TPM?

Yes, yes, it creates a log and saves this.

I'll pick up the next one. Is the TPM available on the latest Jetson Orin developer board? I believe the question is about developer kit. That's what we call. Is the TPM available on the latest Jetson Orin developer kits?

Yes. The SEC-TPM is available on the Orin developer kits. It can be loaded and tested there, obviously, for production -- better production modules.

One thing that I would like to add here is we have worked with SecEdge on developing our TPM solution. The TPM solution on the JetPack is going to come in the next JetPack release which will be around 6.1, but we may release the TPM even before that 6.1 release. We might release just on the TPM after a 6.0 GA release. But SecEdge is already -- can provide you with the TPM solution even before we have it on JetPack. It's just that our release of 6.0 GA might not include the TPM, but we will release the TPM and measure good functionality after that on JetPack. But you can connect to SecEdge for your TPM and measured boot needs. There is a question on trusted applications. Can the trusted applications which are executed inside the trusted OS, can they be executed on GPU? Or in other words, do they have access to the GPU?

So the trusted applications run within the TEE, which is run as part of the TrustZone Architecture. So the trusted applications themselves run on the ARM cores. The GPU and leading AI and machine language, our machine learning models to the GPU is a separate thing. So, yes, so the trusted applications themselves are meant to be small. Targeted specific security functions are more simplified, and they run specifically on the ARM cores as part of the TrustZone TEE architecture, not on the GPU.

Yes. The obvious next question would be the Jetson module is for doing inferencing and running ML workloads, then what is the use that the GPU cannot be accessed for inferencing from trusted OS? I believe the trusted OS, what you run in the trusted OS is for a different purpose, while the machine learning and the AI models are running on the normal Linux world. But you can probably -- Mike, you can talk about how you do model protection where the models are still running in the Linux -- normal Linux. But how do you use the customer application to encrypt and secure the model? You can explain that.

Right, right. So I think that during the presentation, as Larry was explaining, the data at rest, so the model at rest on the nonvolatile memory is encrypted and locked to that specific device so that in the event that somebody has -- because these are edge devices, they're more accessible, that they would be -- if somebody got physical access, they couldn't take the model off of the nonvolatile storage. And -- because it's encrypted. Or if they did, it would be unusable. And then the TrustZone is used -- or the trusted application is used to decrypt that model at run time and load it and have it loaded back to the GPU for running and doing the inferences there. So it's more for holding the keys encrypting, decrypting, providing the security features of the device. It's also used for models in transit. So when you're updating your models from a [ newer ] site, it's the basis for the IPsec tunnels so you can establish those tunnels. And it's also used for the model that you move down, you can -- I'd say that you have the encrypted model and you want to make sure it's stored encrypted so you can use the trusted applications for the security functions, not for running the model itself.

That explains, I feel, that question. The next one, I think this is for me. When will be the final release of JetPack 6.0 will be available? I feel the question is about when will be the JetPack 6.0 GA available, and the answer is on May 2 is what we're targeting right now. It got pushed because some of the regressions that we saw and some of the [ bulk cases ] that we wanted to make sure we put it in inside the 6.0 GA. But again, that is going to be the 6.0 GA release. It's not going to be the final 6.0 release. If there is a roadmap of 6.0 releases, which we'll be doing, like we plan to do almost like 2 releases in a year. So the next 6.0 GA release will be on -- targeted on May 2. So that is that. Okay. Let me pick up another question. So are the secure VPNs over separate or singular transport? It's all about the sec VPN question. Is it over separate or singular transport?

So the IPsec tunnels are over a single -- well, if you've got a single physical layer connected, then they'd be using that transport for the IPsec tunnels. They can -- you can have multiple IPsec tunnels running to different destinations, entering and exit points there. But typically, in these scenarios, if you have multiple layers, you can figure the routing and the tables to set them up on the different physical transport. But typically, it's a single transport coming off of these edge devices. If you have something in the middle of a gateway device, it may be something -- you may have multiple and then you can segment it, then route instead of your networking that way as well.

There's a related question. If let's say Orin is operating over Ethernet and LAN and not on WiFi, will that be secured too? With sec -- I believe...

Yes, the IPsec tunnels themselves are protecting the IP, so it doesn't really matter what physical layer you're using. Whether or not it's WiFi or Ethernet, that doesn't make a difference. The IPsec can kind of run -- would be over whatever IP channel is present, so...

Question on the TPM. Is the TPM 2.2 or not? And I think the answer is yes, it follows the TCG TPM 2.0 standards. Do you want to add anything, Mike?

No, that's -- yes.

Okay. Is it possible to -- I believe it's something that we have already answered, but is it possible to deploy encrypted model on the Jetson? If you want to add anything on top of what you've already answered, feel free to do so.

Yes. I think both the communication deploying, the channel can be protected with the tunnels and then the model itself is protected at rest and encrypted and can be keyed specifically for that device as well. So it is the heart of what we've been talking about.

There's a question, probably I can take this. Can you please address the differences between Jetson and Orin family of processors with regard to security features? So when it comes to security features, what we enable from the software on Xavier and Orin, like secure boot, trusted OS, security engine, the encryption of disk and memory, rollback protection, physical attack measures, the one slide that I was showing in the starting of the presentation. All of these features are supported on Xavier and Orin. The place where it differs is the TPM and the measured boot will be available only on Orin. We would not support that on Xavier. So apart from the TPM measured boot, all the other feature set for security remains the same between the Xavier and Orin when it comes to software improvement. Okay. Let me pick up another question. Do I need to burn fuses when I test? I'm not sure what is the context of it. Mike, do you want to take a stab at it?

Yes. So typically, a big part of this, and there was a part that I think Larry showed that for production, you end up burning fuses and sending the secure boot and sending unique keys and everything. But during the test class, during the development process, it's not necessary -- the features are available and you can use -- you can test all of this on a development board without actually having to burn the actual fuses. So you don't have to worry about in the development phase, having to go through a lot of modules for that. Just when you get to production, you typically test a few and burn some fuses to make sure everything is working right, but not during the development phase, you don't have to burn fuses.

Thank you. There's a question on -- is the performance affected by AI model protection? Or does the SEC-TPM AI model protection affect performance?

Not -- the use of the TrustZone and the TEE doesn't affect performance. And running the model, it's not -- it doesn't affect the performance of running the model. If you're not encrypting your models right now, there will be a small delay in encrypting the model when you go to load it, but that's pretty insignificant. So overall, the performance impact is very minimal. And the only impact is if you aren't doing any production of your models now and you start adding some encryption to it, it's going to add a little bit of delay in opening the model, but nothing significant. And that's the difference between using security and not using security, not this particular solution.

There's a question that just came up. I'm picking it up right now. I thought JetPack requires the next desktop as I read it on its web page or even production system on your desktop or not. I can take that. No, I think most of the solutions deployed with Jetson, for example, say it's a robotics application or a smart camera or maybe a retail analytics solution, none of them have, like, for example, have a display connected to it. But there are other use cases which might have display connected to it. So just up to your use case, what do you want to -- what use case you require? And if you do not need this -- if you do not need a display, you can disable all the display-related or the desktop-related functionalities from the JetPack. So yes, it's not necessary that you have to have a desktop for you to put production with. Is the model encryption being talked about different from LUKS disk encryption? Or is it the same?

Yes. So the LUKS disk encryption typically is based on dm-crypt, and it's in the Linux driver so that everything written and read through Linux to the file system is encrypted with those keys. And so any compromise of Linux has access to that data. With the encryption that we're talking about is using the TrustZone and the TEE to do that encryption. And that is completely separate from Linux. It's a different OS that's running on the chip. So that does not -- it is a different encryption method, and Linux doesn't have access to those keys directly. So it is different than the LUKS disk encryption that you typically see. And it is using keys that are outside the control of Linux and outside the visibility of Linux. It's using the TEE TrustZone.

Thank you. Does the SecEdge solution support Orin as a PCIe endpoint? I believe -- the question, I believe, would be like Jetsons can sometimes be used as a PCIe endpoint. For example, it would be like an accelerator, an AI accelerator in which case...

Yes. Yes. So essentially, at that point, yes, you can terminate the IPsec -- you could terminate any IPsec tunnel directly into the Linux that was running there. And it would be -- yes, that is a -- it is the edge endpoint directly on the Jetson device. Yes.

Thank you. There's a question. What are the system requirements to be able to use the turnkey solution? I believe it's this SecEdge turnkey solution.

I'm sorry, I didn't quite hear...

What are the system requirements to be able to use the turnkey solutions?

The Jetson -- I mean, if you're using one of the Jetson modules, having connectivity for the [ SV ] connected device, but the module -- the Jetson itself is pretty much the requirement. Trying the TrustZone TEE and then we provide the SEC-TPM solution as software to be loaded, and it runs on the Jetson. And I don't know that there's additional requirements there. I mean Jetson is capable of supporting the solution. So -- and because it comes -- because it's a module and not just a chip that you're designing around, it has the capabilities with it. So...

Thank you. There's a question. I think I believe it's a repeat, so probably I'll just -- can you talk about the performance of the solution? I believe it is the SEC-TPM and AI model protection. I think we've already answered that. Okay. There is a question. I missed the part of the webinar, unfortunately. Was it recorded and can we access it somewhere? Yes, the webinar will be available as an on-demand, so you can come back and with the same link, you should be able to see the entire webinar again. So don't worry about it if you have already kind of missed some of the portions, you can go back and check the webinar recording. There's one question. I see you're using keys for encryption. How do you prevent using quantum computing to decrypt to separate a file?

So I think when we talk about quantum resilience because the SEC-TPM is a firmware TPM, it can be updated over time. There are algorithms that are being -- that are developed and this recommends that they are quantum resilient algorithms. And so as appropriate for a particular application, then because it is a firmware TPM and software, we can implement those and deploy those as software even if the hardware doesn't have necessarily hardware acceleration or hardware to run those algorithms. We can deploy separate software algorithms for those, and those algorithms are -- do exist. So -- and we -- that's how we have the quantum resilience, is because basically, crypto agility in general and quantum resilience just falls into that category. So algorithms are designed specifically around the types of flaws that can be exploited through quantum computing.

Does NVIDIA have plans to release documentation on how to secure [ UEFI ] given the customizations NVIDIA has performed? We are looking into it, and we should be having a documentation on it, that release, a little bit later than that, but we are looking into that. There was another question, why do you choose IPsec over a different technology like WireGuard?

IPsec is a well understood and well deployed. And it is solid encryption tunnels. We used it. It's connection is like something like [indiscernible] which is not a connection-oriented -- it provides a persistent connection and it is using encryption. And that is -- it's well understood. I don't -- we can go into specific comparisons with other ones and answer this as follow-up, I think.

Sure. So it's micro details. I'll leave it up to that. Does this SEC-TPM has countermeasures against physical hardware attacks such as site channel attacks, port injection attacks and optical probing attacks?

Yes. So some of these -- we do -- it's easier -- some of those are more hardware-specific and some of those are about co-construction and the way that those are [ put about ]. So we do have an analysis of site channel attacks and which ones we directly address -- that are able to be addressed directly with software and which ones are sort of more dependent on the underlying hardware and just kind of go through this. So it's not a simple like, here is -- yes, we protect against all countermeasures. You have to kind of go through and look at them specifically as to how each one is addressed. Sort of power leveling or active shielding is much more of a hardware type of protection versus like the differential power analysis or timing analysis. Those can be maybe leveled through software as well. So yes, we do -- we have done analysis against different site channel attacks and have sort of countermeasure remedies and our mediations and what we can and can't -- what can be addressed and not addressed directly.

So there is a question on the -- why can't I see all the questions? So the reason is that when the questions are coming in, we are trying to answer it by text and whatever we answer by text is something that you guys can see. There's a lot of questions filed in that we couldn't get time to answer on text. That's why we're picking it up in the Q&A and answering it live. So that is the reason. I hope I answered that. I think I'll take the one last one because most of the questions now are very repeated in nature. So I'll take one last one here. Okay. This is about the process of SEC-TPM and how you work with the manufacturing and such. How can we give manufacturing the rights to generate and sign encrypted key blocks without giving them rights for the PKCS stored in the devices?

Yes. So we don't give many rights to the -- I assume if -- by manufacturing, you mean like a third-party manufacturer, somebody who is outside of the direct path. We use -- NVIDIA provides the ability to create encrypted [ feed logs ]. And then from this encrypted feed logs you can create the encrypted and signed payloads before it ever is delivered to your manufacturer. And this is the process that we use so that we don't have to provide those keys and our pieces to the production line, however, that's being manufactured. Everything that's going there is encrypted and signed, payloads, they get loaded to the device. And that's using the [ FSKT ] process that NVIDIA provides.

Yes. Thank you. I think that was our last question. I'm feeling like most of them are now kind of -- have exhausted or either they are all repeated questions in one form or the other. So thanks all for joining. What you can also do is download the PDF which comes with this webinar. On the last page, there is a contact for SecEdge. So please do contact SecEdge, if you have any further security questions related to their offering or if you would like to know more about the SecEdge offering for your security needs. Thanks a lot, guys. Have a good -- what is today, Thursday.