Skip to content
InTechnology Podcast

#47 – What That Means with Camille: Cryptographic Services

In the previous episode of What That Means, Camille delved into the world of post-quantum cryptography. Today, she explores cryptographic services with Eduardo Cabre, who is a Principal Engineer with the Intel Product Assurance and Security Division; they discuss the future threats organizations will face and possible preventions.

We cover:

  • The difference between the two kinds of cryptography – symmetric and asymmetric
  • What exactly is meant by attestation
  • What “keys” are and how they’re generated
  • Why encryption is crucial for protecting things like biometrics
  • How much of a threat quantum computing could pose to public and private keys in the future
  • What kinds of new cryptographic services are in development

… and more

 

Be sure to tune in, and also check out WTM Episode 46 if you haven’t already for a great companion piece!

 

The views and opinions expressed are those of the guests and author and do not necessarily reflect the official policy or position of Intel Corporation.

 

Here are some key take-aways:

  • Cryptographic services are essential to securing data in computing devices.
  • There are two types of cryptography – symmetric cryptography and asymmetric cryptography; symmetric cryptography deals with the process of encrypting data (typically in very large volumes), while asymmetric cryptography can be used (for example) to authenticate to a remote system using TLS or some other authentication protocol.
  • Cryptocurrency uses asymmetric cryptography.
  • Quantum computers are good at breaking asymmetric cryptography, quantum-resistant algorithms are in development through organizations like NIST to combat this threat.
  • The cryptography system is implemented at a very, very low-level hardware trust level, and is not happening in your CPU.

 

Some interesting quotes from today’s episode:

“Users expect computing devices to protect their data against unauthorized access, and to do so, cryptography is a very critical tool.”

 

“The device changes hands a number of times prior to being deployed, and so certainly attestation can be utilized to confirm that the device that you purchase is the device that you received. But in addition to that, attestation can really be executed at any point in time you want.”

 

“Certainly the private key is the most sensitive part of the key, and so you want to protect it as best you can. If that key leaks, then whoever obtains access to the key can then impersonate that device.”

 

“As long as the key that is used to encrypt that data resides locally on your device, the encrypted data could live anywhere.”

 

“Anybody that has access to the public key and a quantum computer will be able to reverse engineer your private key. And that’s bad news when that happens.”

 

“Basically, most network security protocols are based on public key cryptography, and all of those will break effectively. Right? So no more TLS, no more MCTP. All those protocols that utilize asymmetric cryptography for the underlying security will break.”

 

“We’re going to be going from hundreds of millions or billions of keys to dozens of billions of keys in the next few years.”

 

“The other thing is there is a new concept of platform root of trust, where the platform internally has the ability to interrogate all of its components, obtain evidence that each one of its components is operating in a trustworthy way before the platform boots.”

Share on social:

Facebook
Twitter
LinkedIn
Reddit
Email

Camille M: [00:00:00] Hi, and welcome to today’s episode of What That Means: Cryptographic Services. We have with us today Eduardo Cabre, who is a Principal Engineer with the Intel Product Assurance and Security Division. He’s the architect of Intel’s Key Generation Facility, or EKGF, which delivers billions of keys and certificates a year for both Intel and also the broader industry.
Eduardo is a recognized expert in high volume cryptographic key generation, key provisioning and hardware root of trust PKIs. We’ll get into some of those details as we go forward. As an architect, he develops the software and security architecture of cryptographic systems, and he leverages his expertise in cryptographic, primitives, technical and operational controls, network security, high availability, and disaster recovery needed to assure key generation and provisioning life cycles.
Eduardo also provides technical leadership externally outside of Intel, such as driving transparent supply chain contributions within the Trusted Computing Group Standards Organization. Welcome to the show Eduardo.

Eduardo C: [00:01:13] Hi, Camille. Thank you very much, uh, and, uh, very glad to be here.

Camille M: [00:01:17] I’m hoping that we can start off–we ran through a whole bunch of different terms, even in the introduction like keys, um, and root of trust–I’m wondering if you can start by just defining. What are cryptographic services in just under three minutes.

Eduardo C: [00:01:35] Absolutely. So cryptographic services are a very important part of securing data in computing devices. Cryptographic services typically consists of the generation of cryptography keys that are embedded into silicon devices, generating digital certificates for those keys and also providing key management and replication capability. And in addition to the, one of the most important aspects of these kinds of services is not only you have to do those things, but you have to deliver them on the very strict technical, physical, and operational controls so that very high levels of trust can be achieved.
Users expect computing devices to protect their data against unauthorized access and to do so cryptography is a very critical tool. Some examples of the security capabilities that make heavy use of cryptography, as you know, are whole disk encryption, biometric authentication, secure boot, and device identity and attestation.
And at this time, the last two are very important because they’ve become very fundamental features of cloud computing. Device identity allows a user to authenticate a computer device remotely, prior to utilizing that device. While device attestation provides a mechanism for the user to confirm that the state of the computer device it’s firmware and the software is trustworthy.
So, um, a very typical use case of device identity and attestation is a customer wanting to, um, execute an accept critical workload in the cloud, using identity and attestation to verify the, uh, compute instance prior to executing that sensitive workload.

Camille M: [00:03:10] So, whereas we might have been familiar with attestation of identity of a person, like, I want to make sure this is actually Eduardo who’s the person on the other end (laughs) accessing the system and the, and the data and the information, you’re saying we can use cryptography or cryptographic services to attest to the identity of the device itself, like the computer or the server, as well as the state, the device is in, in terms of we know whether it’s got the latest firmware image we expect it to have, or whether something else might’ve been substituted in without us knowing it.

Eduardo C: [00:03:49] Yep. That is exactly right.

Camille M: [00:03:51] So look, let’s dive a little deeper. The first thing I’m wondering is, is there a use case where somebody might want to verify the identity and the state of a system, like every single time they’re accessing it? Or is this like a once and done kind of a use case where you’re just going to check when you receive a system from manufacturing that it’s in fact what you ordered?

Eduardo C: [00:04:23] Yeah, that’s a very good question. As a matter of fact, um, both use cases are valid. There is a supply chain use case where you could use these technologies to when you receive the device physically into your, let’s say your enterprise environment or to your deployed environment, you can utilize attestation to make sure that that device has not been compromised in transit right through all the supply chain.
The device changes hands a number of times prior to being deployed and so, so certainly attestation can be utilized to confirm that the device that you purchase is that the device that you received. But in addition to that, um, attestation can really be executed at any point in time you want. Uh, there are mechanisms to do that, uh, And services that, for example, you can call an API, you can send the, um, uh, measurements of the system, and then the API verifies those measurements and sends you a signal back to you saying, “yep, those are the measurements, you know, the state of the system that you, that we expected to have.”

Camille M: [00:05:20] So I want to back up a little bit and just make sure I understand what keys are when you say cryptographic keys or Intel’s Key Generation Facility. What, what exactly is a key and how are you generating it? Where are you keeping it?

Eduardo C: [00:05:38] Sure. So there are two types of cryptography, symmetric cryptography and asymmetric cryptography. Uh, symmetric cryptography deals with the process of encrypting data, typically in very large volumes. Right. Uh, and it is symmetric because you utilize the same key to encrypt and to decrypt. Okay. And so those keys, as I mentioned, are typically generated in a very large data center, utilizing, uh, hardware security modules, which are basically specialized hardware that create these, these random numbers–this is basically what cryptographic keys are, very large, random numbers. Those keys are their, provision onto the device during the manufacturing flow.
There is also the concept of an asymmetric key, where you provide a private portion in a public pro portion, the private portion, which is the secret, is embedded in the device during the manufacturing process. But the public portion is typically signed and put into a digital certificate (1:52), which is then distributed to all the parties that want to do the authentication and attestation against that, uh, against that device. And so those are the two primary cryptographic methods.

Camille M: [00:06:49] So what would be an example of like if you’re an IT organization. Which kind of cryptography are you using symmetric or asymmetric?

Eduardo C: [00:07:00] You would use both. You would use symmetric, for example, when you want to store sensitive data in a database. Okay. So you will have an enterprise environment, you want to have your corporate data, your top-secret data stored in a protected fashion, you will use symmetric cryptography for that. In scenarios where you want to, let’s say, uh, authenticate to a remote system using perhaps TLS or some other authentication protocol, uh, asymmetric encryption is used.

Camille M: [00:07:34] You said one’s called public and one’s called private key?

Eduardo C: [00:07:39] Yeah, correct. And that’s specifically public key cryptography where the cryptographic key is split into two values–aA value that is, is private, that, that you hold the entity hold and other value that is, is public that the verifying party holds. And so the way that it works is, you can then, uh, when you send me a message, you can sign that message with your private key. Once I receive a message, I can verify the signature on that message utilizing your public key. And because I know this public key is yours, I can confirm that this message in fact came from you.

Camille M: [00:08:15] So I know that, you know, cryptocurrency–we could list Bitcoin, um, as an example of a cryptocurrency–uses cryptography. And I know that cryptography has a lot of use cases that are much broader than that as well. Um, what kind of cryptography does cryptocurrency use?

Eduardo C: [00:08:36] Uh, cryptocurrency uses asymmetric cryptography. When you say that you have a Bitcoin wallet, okay, really what you have is the private portion of that asymmetric key. So when you have is a private key—stored, let’s say, in your system or in your, you know, in an app and you’re, and you’re in your phone or whatever. And so what happens is when you do a Bitcoin transaction, effectively, all you’re doing is you’re signing a token that says I am transferring five Bitcoin to Camille. Okay. I then sign that message with my private key. And then I embed that message into the blockchain. And, um, that’s effectively the mechanism to confirm that in fact that transaction happened. Otherwise there was really no other way to tell that I was the person that initiated that transaction.

Camille M: [00:09:27] So what other kinds of use cases are there today besides cryptocurrency for, for this type of thing?

Eduardo C: [00:09:34] Well, uh, as, as we were talking before, um, um, attestation is a very, uh, big use case. And so, um, uh, like in the cryptocurrency scenario, in attestation, you embed a private key into, let’s say the platform or device, right? Uh, and you have the public key, which you trust because he has a digital certificate associated with it. When you interrogate the device and you ask the device, “Hey device, I want to know whether your state is trustworthy?” What the device is going to do is that the device is going to make a basically calculate a hash of the firmware that is running. Okay? It’s going to then sign it with his private key and send that information to me–the hash and the signature. When I received that, what I do is that I valley I verify this signature so I can number one, confirm that that message came from you, and in addition, I will compare that hash to a database of trusted has values. Okay?
So if you send me a hash of your firmware, I can then compare the hash against the database says, “oh, yep. That is the version of the firmware that, um, you should be running at this moment.

Camille M: [00:10:48] Okay, so who is generating the public key if I’m generating my private key?

Eduardo C: [00:10:54] So the entity that produces the key produces, both the private and the people. So typically the way that he works in, let’s say in the, in the embedded devices, you have a data center, right? Or a facility where you generate these key pairs–public and private key pairs–in very high volume. You take the private key. You embedded into the device during some manufacturing process–typically fusing them into, uh, a secure set of fuses in, in silicon directly–and you keep the public key. You sign it and you publish it since it is public, anybody should actually have access to it.

Camille M: [00:11:31] So the private key now you just said it can be put into the silicon itself. Are, are they ever just stored in software or are they always in the silicon?

Eduardo C: [00:11:41] Well, um, they, they could be stored in, in software or some other mechanism, although it’s not very common. Uh, certainly the private key is the most sensitive part of the key and so you want to protect it as best you can. If that key leaks, then whoever obtains access to the key can then Baskar rate for valid device, right? Can impersonate that device. So you don’t want that. And so, uh, you know, the generation of the keys is important and as important, is where you store that key and how you protect it once the key is on, on the, on the part itself.

Camille M: [00:12:17] So what kind of a place to store is secure?

Eduardo C: [00:12:22] Uh, yeah, so, so typically what happens is there, There is a region of gates inside the device called secure fuses, okay? where keys are placed. And so there is then a specialized controller, uh, the fuse controller, basically the only piece of the circuitry that has access to those fuses.
Right. And that circuitry protects access to the fuses and then grants access to only the parts of the silicon that need it–he most trusted parts of the silicon, like a hardware root trust, for example, like a TPM or is security manageability engine, for example.

Camille M: [00:12:57] When you talk about keys and biometric keys, what is that? Are you talking about using like fingerprint as a stand in for a key? or are you issuing a key around the fingerprint? I don’t understand how those two things intersect.

Eduardo C: [00:13:15] Yeah, that’s, that’s a good question. Um, primarily the use of cryptography there has to do with protecting the biometric measure. Okay. So let’s say when you, um, program your laptop for the very first time with your fingerprint, right or your iris scan or whatever, biometric, uh, what the system is doing is obtaining a picture of your fingerprint. Okay. And then typically just hashing that information into a secure hash value–which is a very long number, you know, perhaps in the hundreds of bytes. That information is then encrypted with a cryptographic key and stored locally into your device.
Okay. So that’s where encryption comes along and comes into play when the fingerprint itself needs to be stored securely in your device.

Camille M: [00:14:04] Okay. So the biometric factor that I’m going to use–whether it’s my, my eyes, my face, my fingerprint–in order to assure that it remains private, it’s not going to like a cloud. It’s actually being stored locally on my device. And my device is saying, “okay, I took the scan, the initial scan, and now I’m storing it down at the hardware level. And so every time you look at the screen or you put your finger on the pad, I’m checking it off against the hardware that’s inside of me. I’m not running that anywhere outside on the internet.” Is that accurate?

Eduardo C: [00:14:45] Well, actually it’s, it’s a good question. Um, because once you encrypted the biometric data, you could theoretically send it to some cloud service, right? As long as the key that is used to encrypt that data resides locally on your device, the encrypted data could live anywhere. But ultimately you’re correct. What’s gonna happen is when the biometric verification happens, the biometric data will be decrypted locally with the key that is just only known to your device, typically inside a TPM or a hardware root trust inside your, your device.

Camille M: [00:15:19] TPM being Trusted Platform Module.

Eduardo C: [00:15:22] That’s exactly right.

Camille M: [00:15:24] So is one kind of these keys–the public or the private–going to be susceptible to quantum computers just quickly busting through the encryption on them? Which set is that going to be a problem for?

Eduardo C: [00:15:40] So if you look at both asymmetric and symmetric encryption in this symmetric encryption side, it is believed that quantum computers are not going to be able to substantially weakened, uh, symmetric encryption. Okay. So the data that you have stored in your machine or in your database that is using symmetric encryption to look at that data, that data it’s probably going to remain secure.
Uh, Quantum computers are very good though on the other hand at breaking, um, asymmetric cryptography. Okay. And so because asymmetric cryptography uses intractable mathematical problems to operate, to basically derive the keys, what quantum systems can do is break the public key and recover the private key from the public. So because the public key is public, anybody has access to it. Anybody that has access to the public key and a quantum computer will be able to reverse engineer your private key. And that’s bad news when that happens (laughs).

Camille M: [00:16:39] And so essentially the way you described it before, where you have symmetric keys, it’s like you’re the owner of both sides of the key. Um, the, the lock and the key. Whereas the public, whereas the asymmetric, you’re probably the owner of the private key and then the public key is available anywhere.

Eduardo C: Correct.

Camille M: So what kinds of things are going to break then? Any kind of data. I would imagine I might store on the internet would be susceptible to quantum compute. Is that accurate?

Eduardo C: [00:17:09] That is accurate. Right? Uh, so, so basically most network security protocols are based on, uh, public key cryptography and all of those will break effectively. Right? So no more TLS, no more MCTP right. All those protocols that utilize asymmetric cryptography for the underlying security will break.

Camille M: [00:17:30] Okay. Is there a plan in the industry for that? (both laugh) Do we, do we, the people have a, have a plan?

Eduardo C: [00:17:39] We do. We do. So what we can do and we’re already doing, uh, we have been known for a few years now is to extend the life of RSA and ECDSA by just making the keys longer. By making the key longer, you would require a even bigger quantum computer to be able to break it.
Now that method of extending the, the key length is going to work for some period of time, but eventually quantum computers are going to catch up. Okay. Or the keys are going to get so long that it’s going to be basically impractical to use them. On the other hand, though, what NIST is doing, and the academic industry is doing–and also corporate are doing–is investing in developing quantum resistant algorithms for asymmetric cryptography. And so there are a number of them already. Uh they’re they’re, you know, that have very good

More From