(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

January 13, 2016 Comments closed

Re-Hashed: Getting Started with Code Signing

in Everything Encryption, Featured Posts

An introduction to Code Signing Certificates and their many benefits

Today, nearly everything is a computer. Our main methods of transportation? Cars, buses, trains… they are all computers. The tools we use to communicate? Cell phones and laptops… those are definitely computers. Even our homes, fridges, and TVs are now computers.

Below the beveled edges, the clean GUIs, and the ergonomic shapes of all these computers, is code. Code is at the foundation of every computer, controlling what it does and how it does it. And for modern devices, code is no longer static. It’s constantly being updated. Sometimes, without you even knowing.

It’s strange to think that the code controlling your phone or your car or your stove may be updated at any time without you knowing. Who wrote that code anyway? Do you know? Does your friend know?

Does your computer know?

That’s an important question. When the devices we all rely upon run code… do they know where that code came from? Do they know it’s the right code? That it’s safe code?

Code Signing Certificates are part of a solution to knowing when you have the right code. Using some amazing mathematics, Code Signings attach an identity to code, allowing us to know who authored it, and have a guarantee that it has not been tampered with. In this article we are going to introduce you to Code Signing Certificates, go through a simple explanation of how they work, and explain why and how you should start signing your code.

The Problem

You are a software developer distributing your software across the internet. You have users all around the world and enjoy moderate success. Do you ever wonder if your users are getting the same exact code you distributed?

If you are distributing unsigned code, it may be difficult to know. Maybe one of those “drive-by downloader” sites grabbed a copy of your software and started distributing it with some bundled adware. Maybe someone uploaded your software to a warez site for free but threw in some malware in the process. If your software is popular enough, a malware distributor could be doing a straight bait and switch – and hiding malware under your file name.

Your users may be wondering the same thing. Is this code legitimate? Should I trust it?

These are real risks and real attack vectors. Historically, masquerading dangerous code as something safe that users want to run has been one of the main distribution methods for malware. Millions of people are looking for Photoshop, Microsoft Office, and Adobe Acrobat, and malware distributors know that. I’m personally guilty of running software online from dubious sources; and everyone knows at least one person who ended up infecting themselves after running some “free” software.

Even well-known sources for software distribution have been sources for malicious applications. Last year when How To Geek tested the ten most popular programs on CNet’s Download.com and ended up with a lot of unwanted and bothersome things.

Sourceforge.com, which was at one time the official repository for many open source applications, has begun distributing malware and unwanted software with legitimate applications, without the permission of the original authors.

So code is not just at risk of impersonation, but of unwanted tampering and modification.

How do we bridge the gap between what code claims to be, and what it really is?

Code Signing Certificates try to tackle this problem by associating code with an identity. When you run signed code, you will clearly see who authored it. That can be extremely powerful information. If you trust that author, you can feel confident running the program

What Does Code Signing Do?

Code Signing certificates don’t sign just any code – they aren’t used to sign a .PHP file or an IF statement. Code Signing Certificates sign executables and scripts. You know these files: .exe, .app, .msi, .cab, .dll, .jar (and many more). By signing these files they provide cryptographic protection against modification, and identify the author of the software.

What exactly does signing mean? If you are familiar with public-key encryption (also used by SSL Certificates), then you will understand how Code Signings provide reliable identity. If not, here is a quick run-down:

1. Every Code Signing Certificate has a unique private key associated with it, which only the owner of the Code Signing Certificate possesses. When code is “signed”, that unique private key is being used to attach a digital signature to the executable script.
2. A private key will produce a unique signature for every executable it signs. This is because the key is signing a “hash” of that executable. A hash is a mathematical tool used to get a unique value from any given string of data, in this case, a file. This is what prevents someone from taking a valid signature attached to one executable, and applying it to their own illegitimate software. When a computer checks the signature, it can tell that the signature was not for the same code because the hash values will be different. Note: Signing and encryption are different things. Both are important and are widely used in cyber security, oftentimes they are used together. Encryption is another mathematical process, which involves modifying data so that it cannot be read by anyone other than the intended recipient. Please be aware that Code Signing Certificates do not encrypt your files/data.
3. When the end user runs the executable, the platform they are using (Windows, iOS, Java, etc), will check the signature and display it to the user. This lets the user know the origin of the software and allows them to make an educated decision about running it.

Remember, Code Signing provides identity. At the end of the day, when you run an executable or a script you have to decide for yourself if you trust that identity/author (be it a person or an organization). Code Signing does not automatically guarantee that the program works properly or that it isn’t intentionally malicious (someone could choose to sign malware, hoping to trick someone into thinking a known author automatically means it’s safe). Code Signing can only guarantee the software is exactly as it was when it was distributed by the signer.

How Code Signing Allows for Safe Distribution

When you need to make a physical document official, you sign it. Your signature, which is unique to you, asserts that you have endorsed, agreed to, or authored a physical work. In the digital realm, we have Code Signings; that use digital signatures which, like a traditional physical signature, asserts identity.

Digital signatures are cryptographically enforceable. This means that computers reading the signatures can prove if they are legitimate, or if they are forgeries. Computers don’t just read the signature and say, “this code says it’s signed by Craig, so it must be true.” Computers inspect the signature to prove that Craig signed it.

In the process, Code Signing certificates also ensure authenticity and integrity. Let’s take a closer look at these because they are both extremely important:

Code Signing can prevent a large number of attacks that rely on unauthorized/malicious modification of code, fraudulent software, and purpose-built malware.

There is a second type of Code Signing Certificate known as an “EV Code Signing” which is used for the highest-sensitivity applications. These certificates have special requirements about key storage and signing and are usually physically mailed to you on a secure flash drive. While most people won’t need to use EV Code Signings, I wanted to briefly mention it.

Timestamping

I want to take a quick detour here to explain timestamping, an optional, but incredibly important part of Code Signing.

Code Signing Certificates have validity periods (like SSL certificates). This is the date range that the Code Signing Certificate is considered “valid.” Code Signings are valid for up to 3 years and are usually sold in yearly increments. When you purchase a Code Signing you will have the opportunity to decide how many years you want to purchase. Once a specific certificate’s validity period is over, the certificate expires. At that point, it is effectively dead.

Once a certificate expires it cannot be used to sign any new executables. On that day the existing signatures will also become invalid. Unless you timestamp.

Timestamping is an additional piece of information added to the signature that tells devices when you signed the code. Like the rest of the signature, it’s cryptographically secure. This allows devices to compare when signing occurred with the validity period. If signing was done during the certificates valid life, everything is okay. The signature will be valid in perpetuity (though occasionally, cryptographic standards will change and the signature will eventually become outdated. However, this does not happen often).

The reason this is so important is due to the way people use executables. If you develop software and start distributing it, you may continue to provide that same exact file for years. Executables are not as ephemeral as web pages and HTTPS connections. So it does not make sense that one day the same software is viewed as valid, and the next day it’s not. Timestamping is essential to maintaining usability over time. It also saves you money as you don’t need to continually buy Code Signing certificates unless you actually need to sign something new.

Most major CAs provide Timestamping, like Symantec, Comodo, and DigiCert. But make sure you check that it’s supported before you buy your certificate.

A Multi-Platform Solution

Code Signing is available on just about every platform. Seriously. If you are developing on Windows, OS X, iOS, Android, Java, Linux, Adobe AIR, or just about any other major platform, Code Signing is available and encouraged.

More and more platforms are making signing mandatory. To distribute software on the official app stores for iOS, Android, or OS X, you have to sign your code. The closer your software is to low-level functionality, the more important it is to sign and the more likely it is for signing to be mandatory. For instance, all Windows drivers must be signed. Even Microsoft Office macros and Firefox extensions require signing.

Even when signing is not mandatory, we always encourage it. It creates a better user experience. No one wants to see warnings about an “unknown” or “untrusted” publisher. And the security benefits are real. Given the risk of running executable code, you don’t want to leave any room for compromise, even if you don’t think you would be a vector for attack.

The Process

Acquiring and using a Code Signing Certificate can be broken down into five major steps:

1. Purchasing your Certificate – Pick a CA you trust and decide the term length (how many years your certificate will be valid for). You will usually be asked to choose a platform that you will be signing on, but for the most part, you can use your Code Signing certificate for multiple platforms if you take a few minutes to convert the files.
2. Verifying your Identity – So far we have talked a lot about identity – but have not fully explained how Code Signing Certificates know who you are. In the verification process, the CA confirms you are who you claim to be before issuing you a certificate. This process varies if you are applying as an individual, or as a company.Each CA does things a little differently, but for them most part it’s a set of standardized procedures that relies on official government documentation. If you are applying as an individual, this means providing notarized copies of government IDs. For a company, you provide proof of legal incorporation. The CA will then confirm these documents through other channels (for example, searching for your corporate records directly with your state/country) to ensure they are legitimate.You should expect the validation process to take 5 business days or less, though the process does rely on you furnishing accurate information and we have worked with some clients who have had the process take longer due to incorrect info or communication delays.
3. Installing your Code Signing Certificate – Depending on what platform you are using, these next two steps may be entirely separate, or one in the same. On some platforms, a signing tool handles both the installation and signing. In other cases, you need to explicitly import you Code Signing certificate into a “trust store” to before you can start using your certificate.
4. Signing your Application – This is where the magic happens! Signing your application is where you add your digital signature. Every platform handles this differently. Check the documentation of your development environment or platform to see how you sign. For many platforms, there are dedicated tools available for this.
5. Distribute your Application – Your software is ready to be sent to your users. When they run the software they will be presented with your identity – and will be able to trust that they are running the legitimate software you provided.You can distribute your software over the internet, on a CD, a flash drive, or whatever method you choose.

Conclusion

I know we covered a lot, so let’s have a quick wrap-up:

Code Signing Certificates sign executable files – anything from .exe to .app, and for every platform in-between. After purchasing and applying for your certificate, you should expect to wait about a week for the validation process before receiving your certificate.

If you develop or distribute software, you should be signing your code. It’s already mandatory on half a dozen major platforms and highly encouraged everywhere else. Signing your code will ensure optimal user experience and prevent those pesky “untrusted publisher” warnings. On top of that, the cryptographic protections of digital signatures will prevent unwanted modification of your code.
Timestamping your code is critical. In most development environments you have to separately set It up, and you should take the extra time to do that. This will ensure long-term usability of your signed code.

Finally, remember that when you develop and distribute software, you are taking part in a large ecosystem of users, devices, software, and bad actors. The weakest areas of the ecosystem will always be under attack, and expectations and requirements for security will constantly be increasing. Get ahead of the threat and start signing your code – your users will thank you, and when an attack is thwarted, you will feel relieved.