In the early days of the internet, one of the first functional problems users faced was how to verify that entities on the other end of a connection were who they said they were. At first, the nebulous nature of online transactions inhibited e-commerce, since buyers feared that their payment information might be hijacked. This lack of trust precipitated the development of digital certificates.

This was not a simple task. When someone places a telephone call, they direct it to a number they already know. They have a high level of confidence that they will be connected to only that number. The internet, at that point in time, offered no such assurances. Sites didn’t know who was doing the buying, and buyers didn’t know for sure that they were connected to a valid seller. Retailers and buyers needed a method to establish trust, or the potential of e-commerce would have been totally deflated.

Public Key Infrastructure

The framework for the answer came to be known as public key infrastructure (PKI). According to IBM, PKI is “a system of facilities, policies and services that supports the use of public key cryptography for authenticating the parties involved in a transaction.” It has the cryptographic public key system as its core, where a public key is mapped to a private key held by a user.

PKI includes a certificate authority (CA) that stores, issues and signs digital certificates. It is a repository for the certificates that can revoke them if they become invalid. The registration authority verifies the actual identities of the parties seeking to store their digital certificates with the CA.

A central directory — a secure location in which to store and index keys — is also part of the PKI, and is a necessary component for high-speed use. This ties into the certificate management system that controls access to stored certificates and delivers those that are to be issued.

A certificate policy dictates how all these components interrelate, including what happens when things fail. Perhaps a certificate needs to be uncertified, for example. That gave rise to a certificate revocation list (CRL), which is just what it sounds like: a public list of all the certificates that a CA has revoked. A browser can determine whether the certificate is included on this list and ignore it accordingly.

The use of certificates gave rise to Transport Layer Security (TLS) protocol, which enables encrypted communicated between two sites. TLS is invoked when HTTPS precedes a site’s URL.

Real-Life Revocations

Real life has a way of overhauling designs. Browsers did not always check CRLs or trust the results returned to them. CRLs are large and need to be refreshed constantly — almost with every transaction. This can give users the impression that the site’s response time is slow, even if it is not.

Another mechanism to deal with this problem, the Online Certificate Status Protocol (OCSP), prompted the browser to ask the issuing CA about a single certificate only. It would then return a response about that certificate’s validity, which took less time to parse than a CRL list.

But there was an implied problem here: The CA would be able to track what sites you were looking at based on OCSP requests. Worse, there was no binding contract present, so the organization would be free to sell that information to a third party without your consent.

Stapling and Certificate Transparency

Some developers thought that attaching the OCSP response to the certificate would fix this problem, since it would be there all the time and not yield a browser’s URL requests to a CA. But an attacker might not want this information to be attached to a certificate. That’s what the Must-Staple flag is for. When a certificate is requested from a CA, a user can require that stapling always be present. If that stapling is not present, the user can assume that the certificate has been revoked and the browser will reject it.

There’s another problem here: What if the CA has been breached or is functioning poorly and issuing rogue certificates? The solution was a CA requirement called certificate transparency, which will be mandatory in certain browsers next year. It is designed to notify a site operator if any certificates are issued for a domain under his or her care. It’s not perfect, but can help to sound the alarm if something goes wrong with the issuance process.

Re-Evaluating Digital Certificates

Revocation of existing certificates has become complex and indeterminate. Symantec, one of the earliest CAs, experienced a massive problem when Chrome moved to invalidate certificates issued by the company. Symantec’s application program interfaces (APIs) were thought to be at fault here, but the net result was the same: Trust was not assured through the use of a certificate.

The entire topic of certificates may need to be re-evaluated. Use cases have become complex and time-consuming. There is no true guarantee of trust, though certificates are a good first step. The internet at large will have to come to terms with how certificates are used and issued in the real world to determine whether the benefits outweigh the risks.

More from Fraud Protection

Unveiling the latest banking trojan threats in LATAM

9 min read - This post was made possible through the research contributions of Amir Gendler.In our most recent research in the Latin American (LATAM) region, we at IBM Security Lab have observed a surge in campaigns linked with malicious Chrome extensions. These campaigns primarily target Latin America, with a particular emphasis on its financial institutions.In this blog post, we’ll shed light on the group responsible for disseminating this campaign. We’ll delve into the method of web injects and Man in the Browser, and…

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

New Fakext malware targets Latin American banks

6 min read - This article was made possible thanks to contributions from Itzhak Chimino, Michael Gal and Liran Tiebloom. Browser extensions have become integral to our online experience. From productivity tools to entertainment add-ons, these small software modules offer customized features to suit individual preferences. Unfortunately, extensions can prove useful to malicious actors as well. Capitalizing on the favorable characteristics of an add-on, an attacker can leverage attributes like persistence, seamless installation, elevated privileges and unencrypted data exposure to distribute and operate banking…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today