Hi, I'm Nick Lethaby the IoT ecosystem manager at Texas Instruments. I'm presenting a multipart training series called Understanding Secure Connectivity in IoT and Embedded Systems Devices.

This is the fourth module in this series, called An Introduction to Digital Certificates. We'll discuss what digital certificates are, how they are issued, how they are validated, and how they are stored on the embedded device. To understand this module it's definitely helpful if you've been through some of the previous modules, especially the one on asymmetric and symmetric encryption.

Let's first discuss why digital certificates are needed. As you learned in the previous module, asymmetric cryptography uses public and private key pairs for authentication of entities. However, when a server receives a public key from an entity that wishes to connect to it, it has no easy way to know whether that entity is trustworthy or not, and it is who it purports to be.

This lack of trust issue is resolved by certificates. Certificates are part of what is known as the public key infrastructure that enables a receiving party to verify the provider of a public key is, in fact, who they say they are.

Certificates, or at least PKI certificates, follow a standard called X509. What a certificate does is complement a public key with information about the issuing entity the receiving party can then further verify through a chain of trust. We'll discuss exactly how the chain of trust verification is done later. But first, let's talk about who issues certificates and what they are.

As we mentioned earlier, a certificate enables the receiving party to validate the identity of the entity that sent the certificate and the associated key. Certificate authorities, which we will abbreviate to CA in the rest of this presentation, validate those identities, and then issue certificates.

The CA signs the certificate it issues with its own private key. And that acts as proof that they can be trusted. Any organization can be a certificate authority, but ultimately they must possess a certificate that was signed by a special class of CA, known as a root certificate provider.

Examples of root certificate providers would be Digicert GoDaddy. Trusted root providers have to follow very stringent security procedures and face regular audits, because any certificate issued off their root is implicitly trusted throughout the internet.

A trusted root certificate provider will not issue end-entity certificates, such as those put in servers or IOT end points. Instead they issue what is known as intermediate root certificates. These root certificates are used by other organizations to implement their own in-house CA where they can further issue other certificates, either to create more intermediate certificate authorities, or to directly issue end-entity certificates.

Later on we'll walk through the whole process of how end-entity certificates are issued, starting from when the trusted root provider first creates a certificate for an organization. This will enable you to fully understand the steps involved.

To get a better understanding of certificates, let's look at what they contain in more detail. An X509 certificate has a number of fields. And there's a couple I want to emphasize right away, particularly in relation to the earlier discussion we had on asymmetric encryption in the previous module. First, there is a public key. A certificate is essentially a way to pass a public key to the receiving party. Secondly, certificates are signed. Signature algorithm along with the private key that is equivalent to the public key contained in the certificate is used to encrypt the hash of the certificate to create the digital signature. This signature value is then contained in the last field of the certificate. In addition to the public key value and the signature, the certificate also contains information that allows the organization to be validated. For example, the subject field tells you the name of the organization that owns the public key, its name, and address. The issue of field gives you similar information about the certificate authority that issued the certificate, and you can use this to help validate the whole chain of trust associated with the certificate. Other fields of interest are validity period. Certificates start and cease to be valid on specific dates. This can be quite short for end-entity certificates, but much longer for root or co-signing certificates.

Finally, key extensions are often used. And we'll discuss the context of those in the next slide a bit more. Let's consider some of the different usages of certificates that occur in I/O applications. One use of certificates is as the root certificate. The purpose of a root certificate is simply to issue other certificates. At the rate base you have your trusted root certificate providers, such as VeraSign. And they would then issue intermediate root certificates to organizations, such as maybe an IoT device company. An IoT device company would then use those intermediate root certificates to either direct the issue to a server and device, end-entity certificates. Or if they're a large enough organization, they might well issue further intermediate root certificates. So each division might have their own root, for example. Root certificates have very long lifetime and are typically valid for a couple of decades or more. End-entity certificates are obviously the most common ones, because they're issued to servers and IoT end points. Since each entity will have its own unique certificate, there literally will be tens of millions of end identity certificates.

End entity certificates may often have quite short validities. In addition, an end-entity certificate will not be allowed to issue other certificates. In the way these different usages certificates are enforced is by using the key extensions we described in the previous slide. And the third frequent use is a code signing certificate. Any organization that wants to be able to download programs and updates those programs over the web typically wants to sign the program or the update so that the actual device receiving that update knows it really came from the correct source.

So the code signing certificates, there'll typically just be one per organization, or maybe one per division, and the same code signing certificate will be put into all the IoT devices, for example, from one company.

And a code signing certificate will be again restricted to signing only. It won't be allowed to either issue certificates, like a root certificate. And it won't be allowed to act as an end-entity certificate. Typically code-signing periods often have a very, very long lifetime. So these are three common usages of certificates. One thing to stress is that these are all still just X509 certificates. And it's really the key usage settings in those extension fields that you use to limit exactly how they get used.

And one other point of interest about certificates is when you're looking for certificates on your computer, you'll typically find them in two types of files, either a .pem file or a .der file. So these are the common extensions used to represent certificate files.

We've introduced a number of concepts, such as trusted root certificate providers, intermediate root certificates, end-entity certificates, and traversing the certificate chain to validate it. What we're going to do in this slide is walk through how end-entity certificates eventually get issued by an IoT device company. And this should give you a clear picture of how everything works.

At the start, you have a trusted root provider. And this might be someone like VeraSign or GoDaddy. They own a trusted root certificate. They are a commercial certificate authority.

An IoT device provider-- in this case we have a smart home company-- will go and purchase an intermediate root certificate from the commercial certificate authority. And that intermediate root certificate is signed by that trusted root certificate owned by the commercial certificate authority. And once it has this intermediate root certificate, it can now operate its own in-house certificate authority.

Now, the smart home company has two different divisions. One is a thermostat division. The other is a smart lock division.

Our next step is now to issue intermediate root certificates to each of the divisions. The reason we do this is to minimize the problems caused by potential future certificate revocations. And we'll discuss that issue later on in the presentation.

So at this point, each division has its own in-house certificate authority. And these now can start issuing the end-entity certificates needed by the division for their products. You'll see that thermostat division will have its own in-house certificate authority. And it will use that intermediate root certificate to issue and sign end-entity certificates for its IoT device end points and the IoT servers in the system. And the smart lock division will take the same approach as well.

Now, if we step back and look at this big picture, you can hopefully understand the certificate chain. If we look, for example, at the end entity certificate for the IoT end point in the smart lock division, that feeds back into the intermediate root certificate three, which feeds back to the intermediate root certificate one, which feeds back to the trusted root certificate owned by the trusted root provider. So that is the complete certificate chain.

And what you'll see later on is that when a certificate needs to be validated, you actually ask not just the certificate, but the complete certificate chain is the exception of a trusted root to the receiving party. And that way they can then validate the whole chain.

I want to walk through, again, the certificate validation process for the smart home, smart lock, end point certificate so you really thoroughly understand how it's done.

The first point to make is that the actual certificate are stopped by a smart lock end point to its server. It's not just a single end point certificate, but a complete certificate chain. So, in fact, the end point certificate plus the intermediate three root certificate and the intermediate one root certificate are all passed up to the server.

At that point, the server now has the complete chain with the exception of the trusted root certificate, and it can start moving up the chain, validating that each certificate was issued by the one above it in the chain.

So if you go back to the original process of how the certificates are issued, intermediate three root certificate, for example, would have issued the smart lock end point certificate, and it would have signed the smart lock end point certificate using intermediate three roots private key. So when the server receives a certificate chain, it starts off by looking at the smart lock end point certificate.

To validate it, it will look at the digital signature contained in the smart lock end point certificate, and it will decrypt that digital signature using the public key present in the intermediate three root certificate that's present in the certificate chain.

Once it decrypted that signature, it will have a hash of the smart lock end point certificate. It will then generate its own hash using the same hashing algorithm that's listed in the certificate and compare them. If they match, at this point it knows that the smart lock end point certificate was, indeed, issued by intermediate three root certificate. And we'll then do the same process for intermediate three root certificate to validate that it was, in fact, issued by intermediate one root certificate. So you can see here, we're walking up the chain to prove that a smart lock end point certificate really was issued by a trusted provider.

Now, when me get back to the trusted root certificate, that is not passed up in the certificate chain. It's expected to be already present on the server or device that's doing the actual validation. And we'll explain how it's there in another slide.

However, you can see here how we're walking up the chain using that private, public key pair model to validate each certificate was, in fact, issued by the one that really did issue it. And finally, in addition to checking that certificate was issued by a trusted party, the validation process also checks the validity period for the certificate to make sure that it is still, in fact, current.

We mentioned in the previous slide that the root certificate originally issued by the trusted root provider is not passed up in the certificate chain. It's expected to be on the actual server or end point that's doing the certificate validation.

This is typically achieved by having some kind of root certificate catalog. And if you look at this example on the left this is the trusted root certificate store that you see inside of the Chrome browser. In practice, these trusted root certificate stores or catalogs generally come as part of the operating system. So Mac OS or Windows will have a trusted root certificate catalog or store. And in some cases, they can be actually part of a browser.

As you can imagine, these root catalogs must be very secure and only allow modifications from approved vendors, which in the case let's say Windows would be Microsoft. Cause you don't want a third party to be able to put bogus root certificates into the catalog.

Now, a Wireless MCU, such as the Texas Instruments CC3220 will also have a certificate store, as would wireless modules. However, with wireless MCUs, you have limited memory space. So the practice there is instead of having all the trusted root certificates available in full, you typically just have hashes of the certificates. And that's required for the developer to actually add the real root certificate that's going to be used for the certificate validation onto the device.

So in the case of an IoT end point device, the IoT vendor is going to know the root certificate for the servers that the end point will attempt to connect to. Because then if they're connecting to a specific end point, they're not randomly going out and connecting, for example, to Google, Microsoft, or Facebook, or just general web addresses. And therefore, the root certificate for the server would actually be pre burnt into the IoT end point device. So it has that and can use that to complete the certificate chain validation.

The steps we described in the previous slides about certificate validation are all mandatory. There is another step that will often be done, which is optional. And it's called checking for certificate revocation. Certificate revocation is needed when a certificate's private key becomes known outside of the certificate authority or the device that owns it. At that point, the certificate can no longer be trusted, because other parties could then forge signatures and do other operations that could compromise security.

It's particularly problematic if the private key of a root or intermediate root certificate becomes known, because then all the certificates issued by that root certificate are now no longer trustworthy.

If you go back to the example of the smart home company earlier, you'll probably recall that we had both a smart lock division and a thermostat division. And they both have their certificate authorities in them.

The reason for that split is that if one division proves to be more careless about security, it means that the certificates of the other division are still good because they were issued off of different root certificates.

So what happens if the private key of a certificate does become known? At that point, it is placed on something called a revocation list, because it's no longer trustworthy. And one of the parts of certificate validation that can be done, although it's optional, is to check for revocation. There is a specific protocol called OCSD, Online Certificate Status Protocol, that is used to check for revocation.

Now, when this first came out, it was used simply to request what's known as a certificate revocation list. It could be sent down so it quickly generated a lot of internet traffic. So to make this process more efficient, there are various options now known as OCSD stapling. And in that case, the sender of the certificate attaches the relevant revocation information to the certificate chain when it sends it. And that way there is no need for additional round trips.

Now, you'll often find when you are using a web browser, it will give you a message about a particular site cannot be trusted. And what that really means is that the certificate of that site is now compromised. And you've probably seen a lot of these notices recently because Google and a number of other browsers decided that the semantics root certificate had been compromised. And then what happens then? When that root certificate is thought to be compromised, the OS vendor or the browser vendor will remove it from its root certificate store. So at that point, when the certificate chain arrives at the receiving party, they will start walking up that certificate chain. And eventually it will point to a trusted root. And if their root certificate store does not contain that trusted root, at that point the validation will fail, and the browser will issue a security warning. So these type of warnings you see about untrustworthy sites mean that the certificates they have were likely issued by a root certificate which was now no longer trusted.

We've spent quite a bit of time talking about certificates in general, including how they're issued, validated, and revoked. I want to spend a little bit of time talking more specifically about how certificates get used in embedded IoT devices. There's really two primary uses. One is secure connectivity and the other is code signing.

For secure connectivity, the device needs to have a certificate. And the server, the IoT device server, also needs to have a certificate. And that allows the IoT device when it connects to the server to authenticate the server using the service certificate chain.

And then the IoT device server can now authenticate the actual endpoint device connecting by requesting the client certificate from the IoT end point.

So each server in the end point we noted earlier requires its own unique certificate. And so they'll have to be individually injected into each device and server. The other uses code signing. Code signing is needed so that the IoT end point device can authenticate any software updates it receives and be sure that it actually comes from the IoT device vendor as opposed to some random attacker.

Code signing is a little bit more simpler to implement because each IoT end point has the code signing certificate, or maybe just a public key that is needed to perform the authentication of the image that gets downloaded.

So typically, each organization is only just going to have one code signing certificate. You might have a case in a large organization where each division has a code signing certificate. But the important point is that any particular set of IoT devices will have the same code signing certificate.

So when we consider these IoT end point devices, how are certificates actually going to be put onto them? Code signing certificates are fairly straightforward, because the code signing certificate, as we said, is the same across all devices. And it only contains a public key. So therefore, security in the manufacturing process is much less critical, cause you're not dealing with private keys. So typically, the code signing certificate will be included in the standard software image for the device. And it can be flashed along with that.

Tierless end-entity certificates are much more complicated, because each end point needs its own TLS end-entity certificate. And also, each end point will need to have a private key that corresponds to the public key in the certificate.

You can approach putting these certificates into a device in a couple of ways. One is to do it using manufacturing. And that can either employ a secure manufacturing process. Or you can go out and buy a dedicated chip, which are typically called secure elements that include pre-burnt certificates and the associated private key.

The second approach is to perform operation at runtime for the certificate signing request. The CSR enables you to go out over your network and request a certificate. To do this the end point must have a public-private key pair.

To give you a little bit more understanding of what a CSR or Certificate Signing Request is, it's a message sent from the end-entity, which could either be a server or an end point to a certificate authority. And it applies for the X509 certificate. All the information you need to fill out the certificate, such as things like entity names, who issued it, signing algorithms are all included in the actual CSR request itself. And also a digital signature is included in the CSR, signed using the private key of the requesting IoT device. When it arrives at the certificate authority, it takes the public key out of the certificate signing request. And then it uses that to decrypt the signature. And then it can then compare the resulting hash value against its own hash, calculated off the CSR. And if these match, it then knows that the requesting IoT device does own the private key that corresponds to the public key.

So at that point, it can issue the certificate and send it to the requester, the requesting IoT device, and simply stores that certificate, and can then use it for authentication in connection to the actual IoT device server, which we'll be trying to authenticate each device that connects to it.

In this module, we discussed why you need certificates. We looked at the contents of an X509 certificate, and then discussed how certificates are typically used in IoT applications. We discussed certificate chains and how they affect how certificates are issued and validated.

We also looked at how you store a certificate on an IoT device. And then we looked at something called a certificate signing request, which is a way to obtain a certificate at runtime.

The next module in the series is entitled, how do common IoT software applications use cryptography? We'll look at how secure connectivity is setup using TLS, how to implement secure over the air updates, and one or two other common applications where security is needed in embedded and IoT devices.

At some point it's likely you'll want to do some actual software development of a secure connected application. I've put a few links here to enable you to get the appropriate software and valuation modules to develop secure connected applications on a TI SimpleLink Wi-Fi device. We have an extensive set of hands on training modules called SimpleLink Academy. And as you go there and select, we'll see a number of examples that deal with secure connectivity, secure storage, and cryptography.