What is a Digital Certificate?

Have you ever heard the term digital certificate? It’s another one of those mysterious computer security buzzwords that gets thrown around sometimes by people who are trying to sound authoritative. It’s also a very important concept to people who are actually computer security authorities. In between these two extremes, there lies the everyday Internet user – someone like you, just trying to stay safe on the web.

Digital Certificates in a nutshell

Digital certificates, in a nutshell, are electronic documents used to verify a digital entity’s identity. That entity can be a website you connect to, a software developer you download a product from, or even another person with whom you want to establish secure communications. Digital certificates are crucial to modern day e-commerce, banking, software development and just about any other type of information sharing that gets done on the web.

Digital Certificates – In Depth

TLS/SSL Protocol

To begin to understand digital certificates, we can start with their usage in TLS/SSL Protocol. TLS stands for Transport Layer Security, and it is the successor to Secure Sockets Layer (SSL) Protocol. TLS/SSL protocol is a system of common rules followed by both client and server computers whenever a client visits an HTTPS website. Before client and server computers can begin secure communication, they must go through what is called a “TLS handshake” – the outcome of which is a secure, symmetric session key that allows for encrypted transmission of data between server and client.  The session key is called symmetric because it is used by both client and server to both encrypt and decrypt transmissions. The session key is called a key, but in reality it is also a lock. More literally, the session key is a unique set of computer instructions that obfuscates –fancy way of saying scrambles – a data transmission’s original contents, such that only someone with the session key’s match can unscramble and read those contents.

Public-Private Key Pairs

Here is where we must now go a layer deeper, and introduce the concept of asymmetric public-private keys. To create a session key during an HTTPS session, your web browser must verify that the HTTPS website is actually an HTTPS website and that it is actually connected to the people or company it claims to be connected to. Enter: digital certificates. During the TLS handshake, your web browser automatically scans the HTTPS website for a digital certificate. If it finds one, it then compares it to its “whitelist,” and if the certificate is on the whitelist the handshake continues and session key creation begins. To make it onto the whitelist, the digital certificate must contain the signature of a trusted certificate authority. This signature affirms that the HTTPS website uses a public key that corresponds to a secret, private key owned only by the entity controlling the HTTPS website. Public and private key pairs are a lot like the session keys described above. They are used to encrypt and decrypt data transmissions, but in the case of standard browsing they are primarily used during the TLS handshake to create the session key. Public-private key pairs are also different from session keys because they are asymmetric and have a much longer shelf life. During a TLS handshake, and in other data transmissions that rely upon public-private key pairs, it is only ever the public key that is shared. Again, think of the public key as a lock: it is given to people who want to ensure that only the person with the matching key will be able to read their data. The private key is never shared because it unlocks the data – and in TLS/SSL-based data transmission it allows for the creation of session keys!

As a result, when a private key gets into the wrong hands, it can be used to pose as a legitimate company and create legitimate, digitally certified session keys to steal client data or money. Fortunately, the only way this can happen is if a company loses their (extremely well guarded) private key. This is because although a public key is connected to a private key, it is practically impossible to derive a private key with a public key alone. It is of course theoretically possible, but it involves lots of time, computing resources, and math – all of which are enough to deter all but the most well-funded, determined, and immortal hackers.

Public Key Infrastructure

Okay, so earlier we mentioned Certificate Authorities – the entities responsible for signing digital certificates. In a Public Key Infrastructure (PKI), the infrastructure followed by most websites you visit on the Internet, certificate authorities are essentially digital identity verification companies: one of the largest ones, which you may have seen appear in your navigation bar when banking online, is Verisign.

In the simplest of scenarios, when a website proprietor, a software developer, or even an individual like you wants to become digitally certified, they go to a Certificate Authority, pay a fee, and apply for certification. The level of certification an applicant receives essentially depends on how much they are willing to pay what they need for their company.

• Tier 1: Domain validation – given to any applicant that proves they have administrative rights on a website
• Tier 2: Organization validation – given to any applicant that can prove administrative rights on a website and validate their identity in one additional way. In many cases, applicants must prove the website is connected to a real organization.
• Tier 3: Extended validation – given to any applicant that can satisfy the requirements in Tier 1 and 2 and also pass a number of identity verification tests issued by the certificate provider. This is the highest level of digital certification a website can acquire. Typically, it is used by websites that exchange financial information.

The CA then checks the applicant’s credentials, and if they are legitimate, the CA will issue a digitally signed certificate, which will include either a fresh public-private key pair or a promise that the applicant’s public-private key pair are indeed a unique match. Since the CA is a trusted authority, any website it certifies can be assumed to be trusted too. In real life, however, digital certification is not so simple. The Internet is a global web of connections, and today there are actually numerous intermediary parties between applicant and CA.

For example, a CA may actually outsource identity verification tasks to a third party Validation Authority (VA). A CA might also utilize a third party Registration Authority (RA) to ensure the security of an applicant’s public key. Certificate authorities can also issue certification authority to trusted reseller third parties of their choosing! All of this makes for a real life environment that is no longer so secure. Simply put: the more links in the trust chain, the higher the probability that any given link will break. Just think of the children’s game, telephone.

Web of Trust Infrastructure

As an alternative to PKI infrastructure, some advanced users utilize what is called the Web of Trust model. Web of trust is essentially a decentralized version of Public Key Infrastructure, where there are no Certificate Authorities and where digital certificates are instead signed by multiple independent parties. These parties can very literally be people that personally know one another.

In the simplest sense, in a web of trust model, someone could create a digital certificate for their website using specialized software. That same software includes functionality that allows other web of trust users to sign the digital certificate, if they know and trust a user. In this way, a web of trust user can achieve multiple signatures and varying levels of trust. Of course, there are still problems with the web of trust model. One is that it requires a lot more technical know-how to operate.

This keeps web of trust models small, in comparison to PKI – even though web of trust is less expensive and allows for more personal freedom of choice. Another slight problem with web of trust is that new users who don’t know anyone within a web of trust model often have a hard time getting people to trust them!

Code Signing Software Downloads

Commonly, the web of trust model is used by independent software developers to establish secure communications and file sharing with remote coworkers. This brings us to our next point: Digital certificates are used for much more than web browsing! On an Internet where just about any software can be downloaded to any computer in a matter of seconds, the process of code signing with digital signatures plays a crucial role in verifying that people get what they’ve clicked on.

Let’s say you go to a HTTPS website, and – now knowing some of the digital certificate basics – you know that at the very least any data you share with that website will only be viewable by the people who operate that website. But, let’s say the reason you’ve gone to this website is that you want to purchase software. How can you be certain that the executable file you are about to download is actually the real software? Particularly if the website you’re buying it from is a third party reseller? And how can you know that all subsequent software updates will actually be legitimate, too? Here is where digital certificates and digital signatures play their role. First, the data of the software download is hashed. Then, that hash is encrypted (i.e., signed) with the software developer’s private key. After that, the software package and the encrypted hash are transmitted, along with a digital certificate and a public key.

The digital certificate is included so that the customer’s operating system can verify the public-private key match against a “whitelist” – just as is done with web browsing. The public key is provided so that the encrypted hash, which represents all of the data contained in the software package, pre-transmission, can be decrypted during verification and compared to a new hash of the software data that is created after the software is transmitted. If the hash that gets created after transmission matches the decrypted hash that was created before transmission, you (or rather your computer ;) can be certain that the software was not tampered with during transmission.

This chain of complexity helps to assure that the software you are downloading is the software you want to download, but it isn’t bullet proof. Just because something is digitally signed and certified, does not mean that it won’t be malware – in fact, the same goes for digitally certified websites as well. The reality is that there are countless certs and countless sigs floating around, and if a malware author gets their hands on one they can fool a computer that is not running an anti-malware into thinking an executable is safe because it is “certified.” Unfortunately, there are also PUPs – potentially unwanted programs which actually are legitimately signed and certified, even though they can be harmful to your computer!

Legally Binding Digital Signatures

Finally, one of the most common and useful applications of digital certificates is in the signing of digital documents. Just like code signing a software package, a private key can be used to create a “digital signature” that can be used to authenticate an official document and to ensure that the document was not altered during transmission. This is extremely useful in a global economy. For example, someone in China wanting to issue a request to transfer funds to someone in the United States can securely transmit that request as a digitally signed PDF. Upon receipt, the message’s integrity can then be verified, just as is done with digitally signed software. In today’s global economy, digital signatures carry legal weight and many governments even use them to authenticate official documents. Additionally, when something is digitally signed it becomes non-reputable.

 This means that the authenticity of the document can not be challenged without challenging the integrity of the private key that was used to sign it. Private keys, by definition, must remain completely private. If a document is digitally signed but the signer claims fraud, the only scenario where the signer’s claim can be true is if their private key has been stolen. If this is the case, a private key must be revoked. One need not be a government official or a legal expert to utilize digital signatures, though. Most document creation applications, such as Microsoft Word, allow for point-and-click digital signing, and if you don’t yet have a digitally certified signature many will show you where you can obtain one.

Digital Certificates and Emsisoft

Here at Emsisoft, we take the protection of user privacy quite seriously. For this reason, all transmissions of sensitive data occurring in our MyEmsisoft are encrypted. To see this in action, simply go to our MyEmsisoft page and click the padlock icon in your URL bar to see that we have been digitally certified by GeoTrust, Inc., a large certificate authority. Additionally, all purchases of our software in the Emsisoft Shop are handled by Cleverbridge, an e-Commerce company which encrypts all financial transactions using TLS/SSL protocol. Other ways we implement digital certificates include:

• TLS protected connections on all Emsisoft forum logins
• Fully enabled TLS at the Emsisoft Helpdesk
• All Emsisoft programs are digitally signed
• All Emsisoft online updates are digitally signed
• All emails sent to and from Emsisoft are sent over TLS encrypted connections, if the other participating servers support it

Bottom Line – Digital Certificates and You

Digital Certificates are just one facet of an increasingly complex, global Internet, and though they are quite useful as an identity verification technology, they are by no means fool-proof. Endemic problems have historically included: corruption at various levels of the PKI infrastructure, man-in-the-middle attacks, and the ever recurrent question of what to do with a digital certificate when it expires. Another issue of huge concern is private key privacy; that is, if a private key is stolen it must be revoked immediately. This last issue was partly why Heartbleed was, and is, such a big deal. Countless private keys were potentially exposed, and to date far from every key holder has gotten a new one. Though this is alarming, it has not by any means stopped the web. Not by a long shot.

In fact, as large and as winding as the Internet has grown, it wouldn’t be an exaggeration to say that the Internet has become indestructible. People depend upon the Internet, so much so that they will use it even it is not secure. We make anti-malware so that our users can achieve a safer web experience, but because one of the biggest threats facing anyone who goes on the web is not even knowing what web dangers exist, we also like to write about anti-malware issues, like digital certificates. Our hope is that this approach will help to make the web a little safer for everyone, by spreading “Security Knowledge” and that, eventually, this knowledge will help to create a more Malware-Free World.

 

Have a Great (Digitally-Certified) Day!