Author: GoeSecure

Digital certificates and/or signatures make your world more secure virtually everywhere you look online. These tools allow you to send secure emails and exchange sensitive information remotely without having to worry constantly that your data might fall into the wrong hands.

But what is a digital signature? What is a digital certificate? How do they integrate seamlessly into your everyday life as both a consumer and service provider (even if you don’t know it)? We’ll answer all of these questions in this article that breaks down the difference between a digital signature vs digital certificate.

Let’s decode it..

Digital Certificate vs Digital Signature: A Look at the Differences Between the Two

Digital certificates and digital signatures are just two halves of the same coin. When you’re talking about a digital signature vs digital certificate, each plays a role in establishing and validating digital identity and aids in helping your organization facilitate digital trust. Digital trust is critical to elevating your brand and helping customers feel confident and secure doing business with you.

We’ll go more in-depth on each of these concepts throughout the article. But first, we know some of you are in a hurry and don’t have much time to read this article. We’ve put together a brief overview so you’ll quickly get the gist of the differences and can move on your way:

Alright, now that we’ve had this overview that highlights a digital signature vs digital certificate, let’s dive a little more in depth into each of these elements…

What Is a Digital Certificate?

A digital certificate is a digital file containing verifiable information about you or your organization that validates your authenticity. Basically, it’s a way for the other party you’re connecting to, to check whether you are who you say you are (i.e., you’re not a fraudster).

Digital certificates are kind of like the organizations that issue certificates of authentication for athletes’ autographs. If I want to ensure that I’m getting hockey goaltender Andrei Vasilevskiy’s signature (Go Bolts!), I’m not just going to buy it from some random person on eBay. I’m going to get it from a reputable source that provides a genuine certificate of authentication.

Likewise, the same concept applies to installing code, software, and other executables from reputable sources. You won’t just download unsigned software from a third-party website that could be counterfeit and contain malware, right? (Please say you won’t.) It’s too risky and leaves you vulnerable to data compromise, identity theft, and a slew of other security issues.

Digital certificates are X.509 files that you’ll find at the heart of public key infrastructure (PKI). They come in multiple varieties that serve various purposes:

• Code signing certificates help you prove the authenticity of your software, containers, and code and protect it against unauthorized modifications.

• Document signing certificates help you prove the authenticity and integrity of your Microsoft Office and PDF files. (NOTE: Not all document signing certificates can be used to digitally sign Adobe PDFs.)
• Email signing certificates help you prove to recipients’ email clients and servers that your emails are legitimate and haven’t been altered. They also enable you to send secure, encrypted messages to recipients who also use email signing certificates.

• Client authentication certificates (AKA personal authentication certificates) help you remotely verify your identity so you can access web apps and other resources online. These are frequently the same certificates as email signing certificates
• SSL/TLS certificates help you prove that your website is authentic (owned by you) and enables your server to establish secure connections with users to protect their data in transit.

What Is a Digital Signature?

A digital signature is something you apply to a specific file (using your digital certificate) to prove that the file was created by you and is authentic. In the most basic sense, a digital signature is a way to prove you’re really you (authentication) and that something you created is legitimate (data integrity). More technically speaking, it’s data that proves your identity and that the digital asset you’ve created and signed hasn’t been secretly modified.

In a more technical sense, digital signatures are the values that result from applying a hash function to the data of the digital asset (software, email, document, etc.) you wish to protect and authenticate. This creates a string of data known as a hash value, which you then encrypt using a cryptographic key.

There’s sometimes a bit of confusion surrounding digital signatures and electronic signatures. You’ll find people and companies within the industry referring to them interchangeably. However, that’s not quite accurate. A digital signature is a type of electronic signature, but not all electronic signatures are digital signatures. It’s kind of like how all fudges are desserts, but not all desserts are fudge.

An electronic signature is the digital equivalent of your handwritten signature, whereas a digital signature is something else that doesn’t always have a visual element representing it. Electronic signatures can often be mimicked or faked, but digital signatures cannot be easily copied or faked.

To learn more about what a digital signature is and when to use a digital signature certificate, be sure to check out our other articles on those related topics.

Timestamping Extends the Life of Your Digital Signature

If you want to get the most out of your digital signature, use a timestamp. Timestamping is a method of proving that whatever you signed was signed at a specific moment. It’s an indelible record that shows when your digital asset was signed or modified. By adding a timestamp to something you digitally sign, you’re also extending your signature’s longevity.

Of course, you don’t always have to timestamp your digital signature; it’s considered an optional feature in some use cases. But timestamping is something you should definitely consider doing when signing software and documents. Why?

• Timestamping your digital signature enables it to be trusted years beyond when your digital certificate expires.
• Adding a timestamp provides a verifiable way to show the precise moment when something was digitally signed.
• Adding a timestamp to your code also mitigates the error messages that would otherwise appear when your digital signature certificate expires. It also means you don’t have to re-sign and release a new version of your asset (unless you changed the file somehow).
• Trying to fake your digital signature’s timestamp would be challenging for cybercriminals to achieve.

There’s a bit of a misnomer that timestamping means that your digital signature is valid forever and will never expire. This isn’t the case. Your signature will eventually expire; it just won’t expire as quickly as your digital signature certificate does.

Digital Signatures and Certificates Are at the Heart of Digital Trust

Nowadays, you always hear people throwing around the term digital transformation, which is all about integrating digital technologies to fundamentally enhance your organization (e.g., increase connectivity and operational efficiencies). But there’s another concept that isn’t just a buzzword and deserves more attention than it receives: digital trust.

Digital trust is everything relating to establishing and upholding trust — it’s the behind-the-scenes processes, compliance, and security mechanisms that make trusting your brand possible for customers. At its core, digital trust boils down to three key elements:

1. Digital identity — Offering assurance regarding your verifiable digital identity so they know you’re real and aren’t a shyster,
2. Data integrity — Providing assurance and the means for customers to verify that they can trust your asset’s legitimacy, and
3. Encryption — Securing communications and data and communications so they can feel confident doing business with you.

Now, I’m going to say something a bit controversial here: you don’t deserve your customers’ trust. While this may sound very negative, the truth is that trust isn’t something customers should give blindly; those days are long gone. In the Age of the Data Breach, trust is something you should — and must — strive to earn.

You can have the fanciest office and IT technologies at your fingertips. But without achieving and securely managing digital trust, your digital transformation is half-baked and won’t live up to your (or your customers’) expectations.

Keeping Your Certificates Secure Requires Careful Management

Your digital certificates and the signatures they create won’t do your business any good if you don’t bother to keep them — or, more importantly, their keys — secure. You see, every digital certificate is issued with a key pair. In the case of publicly trusted certificates (such as the ones we’ve mentioned that are used for external uses), that keypair includes a public and private key. Public keys are available to virtually anyone, but private keys are secrets that must be protected.

As of 2020, Keyfactor reported that the average business’s IT environment has an average of 88,750 digital certificates and keys to authenticate systems and secure data. In 2022, Keyfactor also reported that the average number of “internally issued certificates in an IT organization alone” has surpassed 267,000.

If a bad guy manages to get their grubby paws on even one of your organization’s private keys, then you’re in for a world of pain. A compromised key can lead to everything from data compromises, unauthorized modifications, losses, and theft to costly data breaches and compliance issues. Not only will your reputation suffer potentially irreparable harm, but your customers may, too. Needless to say, this will have a devastating effect on your bottom line.

This is why it’s essential to carefully manage and monitor your PKI. This entails keeping visibility of your IT environment and the certificates and keys within it, managing who have access to your keys and resources, and rotating out certificates and keys as they expire or, on the rare occasion, become revoked.

A carefully managed PKI helps you achieve digital trust and makes for a healthy and successful business.

Final Thoughts on a Digital Signature vs Digital Certificate

As you’ve learned, digital signatures and certificates aren’t so much an either/or kind of thing: you need both to secure your organization and its data. To assert your digital identity, you need to use a digital signature. In order to create a digital signature, you need to have a digital certificate. But when creating your digital certificate, a reputable third party (i.e., a CA) must use their trusted root’s digital signature to offer assurance that your organization has been properly vetted and can be trusted… it goes on and on.

If you want your organization to avoid making the next data breach headline, you must secure your digital identity, data, and communications. Carefully manage and use digital certificates and signatures together to achieve this goal.

A software bill of materials lists the “ingredients” in a software product, making it easier to identify and avoid security risks

Unless you’ve been living under a rock the past few years, you’ve likely at least heard of Log4j. This is an Apache open source library that’s commonly used in just about everything Java-related online. Unfortunately, in late 2021 the logging package was discovered to be critically vulnerable to remote code execution attacks, meaning an attacker could exploit it to install malware (e.g., ransomware) onto vulnerable systems and inject larger networks.

Cloudflare CEO Matthew Prince reported on Twitter that there were 400 confirmed exploit attempts per second. But that’s just one estimate — according to The Washington Journal, Akamai Technologies said it observed 10 million such exploit attempts per hour. Research from Check Point also showed that the attackers were rolling out new variants of the exploits — more than 60 in under 24 hours.

That’s a lot of exploits and a lot of variations to boot. Considering that the Log4j vulnerability affected major companies like Amazon, Apple, and IBM, it’s no surprise that it had companies globally worried.

But what makes the situation particularly concerning is that many companies weren’t aware that the products they use contained such vulnerable elements. If only there was a way that organizations could know exactly what components are part of the software they use… Oh, wait, there is: they could use products that come with a software bill of materials (SBOM).

But what is a software bill of materials and how can it help organizations mitigate some of the cyber risks facing their organizations and networks?

Let’s hash it out.

What Is a Software Bill of Materials (SBOM)?

A software bill of materials is a list of the base elements (such as code libraries) used to create a product. Basically, it provides details and information that outline the relationships between the various elements of the software in your supply chain. The National Telecommunications and Information Administration (NTIA) has a bit more technical definition for an SBOM, describing it as “a nested inventory for software, a list of ingredients that make up software components.” It includes everything from version information and what companies created those elements.

Putting it more simply, SBOMs enable companies to know exactly what goes into their software — ideally, so they can keep a close eye on any dependencies. So, going back to the Log4j example, if you’re using software that includes the vulnerable library, you would know instantly because Log4j would be listed in the SBOM. You could reach out to your vendor to ensure they’re providing a patch using an updated version of Log4j. But you can’t assess or mitigate specific cybersecurity risks if you don’t know they exist. This is where an SBOM can help.

An analogy that’s commonly used to describe these lists of components is the ingredient labels on packaged food items. (We’ll speak more to that in a minute.) The purpose of an SBOM is to create transparency and help companies identify dependencies in their software supply chains. This is because, as a purchaser, you’re supposed to receive or be able to access SBOMs for products you purchase. This way, you know a good amount of information about your supply chain.

SBOMs are something that can be used to address a wide variety of security issues for everything from software to IoT devices.

Even the U.S. Government Encourages Using SBOMs to Improve Security

In fact, the May 2021 U.S. Executive Order (EO 14028) on Improving the Nation’s Cybersecurity calls upon the use of SBOMs to help strengthen the defenses of U.S. federal information systems. (Government agencies are now required to collect them from software suppliers.) The National Institute of Standards and Technology (NIST) developed the Secure Software Development Framework (SSDF) to aid this initiative, and it requires software bill of materials information to be included.

NIST says that SBOMs are complementary to other software security processes; they’re not meant to replace other security-related functions such as cybersecurity supply chain risk management (CSCRM) activities.

What Types of Information SBOMs Should Include

In its 2021 Multistakeholder Process on Software Component Transparency document, NTIA explains that an SBOM typically includes specific information about a product’s baseline components:

• Author’s Name
• Supplier name
• Component name
• Version string
• Component hash (yup! Cryptographic functions play a key [excuse the pun] role here, too)
• Unique identifier
• Dependency Relationship
• Timestamp

For a complete list of minimum requirements, check out NTIA’s SBOM Minimum Elements Report. It breaks down the minimum elements that should be addressed in an SBOM into three main categories:

1. Data fields,
2. Automation support, and
3. Practices and Processes.

Do SBOMs have to be created at the time you’re developing your software? Not necessarily. You also can create SBOMs retroactively. The only thing to note about that is that it might not be as complete as an SBOM that’s generated as part of your software development life cycle (SDLC) process.

SBOMs Are Typically Meant to Be Read By Machines, Not People….

An SBOM isn’t something that just anyone can look at and read easily; it’s presented in one of a few standardized formats that are readable by computers (but not human beings, unless you know what to look for) to improve integration and automation. These three standards (listed in alphabetical order) include:

• CycloneDX, which also works for software-as-a-service (SaaSBOM), hardware bill of materials (HBOM), and other uses. The file format for this type of SBOM is .xml.
• Software Identification (SWID), which is also an international open standard (ISO/IEC 19770-2:2015, updated 2021). Acceptable file formats are .json and .xml.
• Software Package Data eXchange (SPDX), which is an international open standard (ISO/IEC 5962:2021). Acceptable file formats include .json, .spdx, .rdf .xls, .xml, and .yml.

Who a Software Bill of Materials Benefits (Spoiler Alert: Everyone)

According to the White House’s Executive Order, SBOMs benefit virtually everyone who develops, manufactures, purchases, or operates software or devices that use said software. But the truth is that a software bill of materials also indirectly benefits the consumers who are served by these companies and service:

“An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability.”.

Yup. While SBOMs are typically promoted as being good for software buyers and operators, the truth is that they’re also useful for broader audiences. So, you see, it’s good for your organization regardless of where you fall in the supply chain.

But now that we know what an SBOM is in a general sense, let’s take a closer look at this security tool and how it aids your organization’s software supply chain.

A Look at How a Software Bill of Materials Breaks Things Down Within the Supply Chain

Your software supply chain comprises everything from where the individual components came from that are used to create the products you use and how they’re manufactured, distributed, and supported. Some categorizations of the supply chain talk about custom code, third-party components, development and building environments, delivery, etc. Basically, it’s all about sourcing your components (internal or third-party dependencies), building your software, storing and deploying it, and providing ongoing support (via patches) while it’s being used by the intended users.

However, to simplify things a bit more, we’re going to look at what the software supply chain ecosystem looks like based on a traditional supply chain (based on information shared in NTIA’s SBOM explainer video):

Let’s imagine, for a moment, that you’re an IoT device manufacturer that uses third-party software as part of your supply chain. This is how the above breakdown would play out with regard to you and your business:

• Source parts refer to all the base elements used to create the product.
• Compound components refer to any elements in the final product that are created using other elements (e.g., a third-party’s library or open source code). Not all software manufacturers provide information about what these components are.
• The final assembled product (your software) is the end product created when you combine all of the parts.
• Operator(s) or vendor(s) is the term that refers to your direct customers or service providers that use your product.
• Consumer(s) refers to the people that your customers use your product to provide services to.

An SBOM Is Like the List of Ingredients You’d Find in Your Favorite Foods…

When you’re at the grocery store, do you stop to read product nutrition labels and ingredient lists? If you’re like me, you do because you want to know exactly what you’re putting into your body.

It’s a good idea to take a similar approach when adding software and devices to your network. If you want to keep your network secure, then you’ll want to check every device, software, or system carefully you connect to it for known vulnerabilities. Knowing what libraries, drivers, operating systems and open source resources are used goes a long way in helping you assess and mitigate vulnerabilities.

Let’s consider a quick example with one of my favorite special occasion meals: Fettucine alfredo. Say, a friend is having a small get-together at her house and I decide to bring over a dish of homemade fettuccine alfredo for the occasion to share. Sounds great, right? It is, so long as no one has any food allergies to any of the ingredients I’m using in my dish.

But how can someone tell whether there might be something in my fettuccine alfredo that might cause an issue? Let’s first consider the list of ingredients. My fettuccine alfredo recipe is pretty simple as it contains several basic ingredients:

• Heavy whipping cream
• Homemade salted butter
• Freshly grated Parmesan-Reggiano cheese
• Freshly grated Pecorino-Romano cheese
• Garlic
• Salt
• Black pepper
• Italian parsley
• Homemade gluten free fettuccine pasta

If I were to break up this item, we’d be looking at the following breakdown of items:

Looks simple enough, right? Not quite… There’s more to it because of the “hidden ingredients” that people might not know about if they aren’t disclosed.

Some Ingredients Are Made Up of Other Unknown Ingredients

A few of these items — the two cheese and the gluten free flour — are created through manufacturers whose products I like and trust. So, knowing this, let’s consider the supply chain for these items — particularly the compound components. These items may have other additives that I might not be aware of unless I stop to read the product label. Let’s consider a quick example using parmesan cheese.

The ingredients for the brand of parmesan cheese I typically use contains cultured cow’s milk, enzymes, and salt. (Note: If I bought the pre-grated variety, additional components would be added, such as cellulose and natamycin — this is why I buy the blocks of cheese and grate them myself!) So, in this case, that means the enzymes and cultured milk need to be added to my list of ingredients.

Likewise, if I looked at the ingredient list for the Pecorino-Romano cheese or the gluten free flour I’d use, there would be several additional items I’d need to add to my list of components. And it would also be important to know where the ingredients the manufacturers used actually came from. For example:

• The Pecorino-Romano cheese I use is imported from Italy and it contains sheeps milk and rennet.
• The flour includes multiple other ingredients — sweet white rice flour, whole grain brown rice flour, potato starch, whole grain sorghum flour, tapioca flour, and xantham gum.

This means my ingredient list now looks more like this:

Why You Need to Know Which Ingredients Are Included in Your Software

See how much longer the list of ingredients became now that we’ve added all of these “hidden” ingredients? Now, ask yourself what would happen if one of your friends was allergic to milk, tapioca flour, or eggs but you didn’t know it. If they didn’t know those ingredients were included in the meal, it could lead to a potentially serious medical emergency, depending on the severity of their allergic reaction.

Likewise, similar concerns apply to your software and hardware devices. While the concern isn’t a food allergy or medical concern necessarily, not knowing what’s included in your software supply chain leaves your organization, network, and customers at risk. Knowing the A-Z of your software supply chain helps you stay abreast of any potential vulnerabilities and exploits you need to address before bad guys use them to attack your network and organization. This is crucial for risk analysis and mitigation activities, where you need to know how and where your systems are vulnerable.

The truth is that it’s rare to find a company that builds its software or hardware components entirely from scratch. (Doing so is just too complex, costly, and time consuming.) Instead, they integrate third-party and open source elements such as frameworks and libraries. When you consider that these components often operate with the same permissions as the software they’re a part of, it means the risk can be significant.

SBOMs help you have a better understanding of your supply chain and everything involved in it. They also help you better manage and mitigate risks by using them to analyze known vulnerabilities. This is why it’s best for them to be stored in a centralized repository that applications and systems can easily access and use.

Can’t a Software Bill of Materials Be Faked?

As with any electronic file, yes, there’s always a risk of that happening. However, there are safeguards that could be used to prevent digital tampering and to prove something is legitimate. One such method is to digitally sign your file before releasing it with your software. A digital signature is a way to simultaneously show that your file is authentic and hasn’t been tampered with since it was signed.

Is a digital signature required for use with SBOMs? No. But as Dean Coclin (CISSP) points out, one good option is to “use a cloud-based code signing service, which allows for uploads of code (or the hash) to be signed by the service and returned to the developer.”

Final Thoughts on SBOMs (And Why They Should Be Part of Your Risk Management Strategy)

Trying to mitigate risks for your software without knowing all the different components nested within it is like going to a dinner party when you have a severe peanut allergy and not bothering to ask if any of the dishes contain nuts. It’s not a smart practice and puts you at risk of a severe medical — err, cybersecurity episode. Instead, ask those questions and avoid the potential headaches, non-compliance issues, financial penalties, and lawsuits that you otherwise may face.

Nowadays, it’s uncommon for software developers to write all of their code from scratch. It’s far more common for devs to integrate open source code into their products because it’s cheaper and easier. As the saying goes: Why reinvent the wheel?

Making software bills of materials a standard component of every piece of software is a smart move. SBOMs provide the added layer of transparency organizations need to keep their data and networks secure and aid in making the vulnerability assessment and mitigation process a lot easier.

The next time you’re shopping for new software, be sure to speak with your vendor to see if their products have SBOMs available. Don’t be surprised if they don’t but be sure to ask anyway to make it clear that this is something you want to see as a software purchaser or operator.