Code Signing

Trusting Downloaded Code

When we've decided to install an application, one of the first things we're going to want to do is verify the source of the code, and we do that through code signing.

We have a user here and they want to install an application. Here's the application, and they got this application from some source. A lot of times we download that from the internet. But the question is, how do we trust the downloaded code? How are we going to trust that this code came from a legitimate source and that we can trust it?

One answer to this is code signing. Just because it has a certificate doesn't mean that this is legitimate code, but it can better verify what the source of the code is, giving some legitimacy to the code. Essentially, what code signing is is a certificate that comes with the software that kind of shows its authenticity, that it came from a trusted source.

Public Key Infrastructure

A core component to code signing is the public key infrastructure, or PKI, and it's really fascinating how this works. In fact, I go much more in depth into the nuts and bolts of it in my cryptography course, and I definitely recommend checking it out at some point in time. I'm just going to give a brief overview of it right now. Essentially, public key infrastructure is a whole infrastructure. It's servers and protocols and certificates, and just a whole way of verifying and trusting some sort of source.

We have a client machine that's connecting into a server, and there needs to be some level of trust there that's happening. The trust stems from a certificate authority. What we have is a certificate authority that essentially verifies the source of information that's being sent to us. So this represents a packet of information that's coming to us, and how do we know it comes from a trusted source? We're going to verify it.

How does that happen? When we install an operating system on one of your machines, whether it's macOS or whether it's Linux or Windows, what ends up happening is it installs some certificates on it. They're called root certificates, and they're of certificate authorities. Essentially Microsoft is saying you should trust these certificate authorities. Apple's saying you should trust these certificate authorities. There are certain certificate authorities that we trust.

So if I'm hosting a website here and I want to have users trust the data that's coming from me and do some sort of authenticity piece, what I'm going to do is generate a public-private key pair and send it off to the certificate authority. They're going to send me a certificate that I can pass with my messages. Then what the end user is going to do, or their computer is going to do, is take the root certificate to verify the certificate that has been handed to them by the server, and once that's verified, that can verify the messages that are flowing back and forth.

Now there's a certain level of trust. There's a trust of this root certificate that comes from the certificate authority, which gets passed to this certificate right here, which gets passed to the communication that happens. So then I can trust that communication that's coming from a specific source.

Signing the Code

It's just as easy to swap out that message that's being sent with code, and so we call this code signing. What happens is that we have code that gets signed by the certificate authority here, and it validates this code coming from a specific source. Then, before we install it on the machine, we can verify once again using this root certificate. We can verify the certificate that comes with this code, then it verifies the code itself, and then we can feel a little bit safer about installing it on our machine.

The Timestamp Problem

There is a flaw to this whole public key infrastructure. It's based off of the information that comes on a certificate, and one of the pieces of information on the certificate is a timestamp, a timestamp of how long the certificate is good for. This becomes problematic, because if it's how long the certificate is good for, then that means our code is only good for a certain period of time. That is, when the certificate expires, the code is no longer good. We no longer can install it, because the certificate is out of date and so it becomes untrusted. So this is a problem with just strictly the public key infrastructure.

Code signing adds this extra step of a timestamp authority, or a TSA. The timestamp authority is involved in this process of verifying the code, and it has a different timestamp, a timestamp that allows this code to still be labeled as being secure. So this happens with this timestamping. The timestamp authority does this timestamping so that when we get it, the certificate still may be out of date, but the code is still considered legitimate at this point in time. So this is code signing, and this is one of the steps that's part of code signing.

A Look at a Signed Installer

To show you what this looks like, I'm on a demo laptop here, and I just downloaded the install file for Adobe Reader. I'm going to click on this, and notice we have the user account control popup, and I can take a look and see that it's verified publisher, Adobe Incorporated. So there's a certain amount of legitimacy that this has, because it's saying it's from Adobe Incorporated.

I'm going to open this up and take a look a little further in depth into it. It says show information about the publisher certificate, and I can see the actual certificate. So this is the certificate we were talking about. This is the certificate that gives some legitimacy to this software that I'm about to install. I can see who it's issued to, and I can find out some information like what the expiration date of that certificate is, and some other information in regards to it.