A Deep Dive into Public Key Infrastructure

Anatolii Padenko
Remme Protocol
4 min readNov 15, 2018

--

Although we think of data encryption and public key infrastructure (PKI) as something introduced for the Internet, it was actually developed in the 1970s. PKI has gone through several iterations of changes and updates, but it’s the traditional methodology for encrypting data and securing communication. PKI supports privacy and protection of data communication between browsers and servers, but it requires implicit trust from a single entity or entities chain called a certificate authority (CA) which has led to a breakdown in confidence. Through the years, having one root entity to control the way private keys are issued to the public has showed that it can cause major complications with transparency and security.

How PKI Works

When you send an email to a recipient, how does this recipient know that it’s actually you sending the email and not a fraudster claiming to be you? Email is one of the most insecure forms of communication, so it can be anyone sending you a message. PKI works to solve this problem using private and public keys.

Private keys are assigned to you when you order them. These keys comprise of a long string of alphanumeric characters specific to only you. Only you should have access to private keys. You also have a public key related to the private key, which is available to anyone who wants to send you a message. A public key is used to encrypt a message sent to you, and only you can open it with your private key. Even if an attacker intercepted the encrypted message, it would be unusable without the private key. The sender is assured that only you can read the message, and you know that the message is secure from eavesdroppers.

The PKI system is also used in web communications. A user’s web browser encrypts data using the public key from the web server, encrypts the message, and sends it to the server. The server’s private key decrypts the message. The certificate installed on the server ensures the client that data is sent to the right domain, and the PKI system stops man-in-the-middle eavesdropping attacks.

Because the PKI system is asymmetric, users need access to a public key and recipients of a message need a private key to decrypt the information. Should the private key be compromised, an attacker would have access to data intended for the recipient. Attackers that gain access to private keys can also eavesdrop on content intended for a recipient and decrypt data as it’s collected. This point of failure is the biggest threat to the PKI system, because compromised keys require new keys to be issued, and old ones revoked.

Lost keys are also an issue for individuals that rely on encrypted data. Lost keys restrict access to messages, and these messages are unavailable forever unless the cryptographic algorithm is weak and can be cracked.

PKI’s Single Point of Failure

Certificates are distributed by entities called Certificate Authorities (CAs). Comodo, Symantec, GoDaddy and DigiCert are just a few poplar CAs to choose from. The Internet and security professionals have given trust to these entities to follow baseline requirements before issuing private keys.

In 2015, Google investigated unauthorized certificates issued by Symantec. Symantec employees issued certificates under Google’s name for testing purposes, but this action goes against baseline requirements that all CAs should follow. Although this seems like a minor incident, a third party with a fraudulent Google certificate could create a domain using the Google name and launch a very effective phishing attack.

The aftermath of the investigation was that Google Chrome would revoke acceptance of any Symantec issued certificates, and as of October 2018 Chrome will display a warning interstitial for any site that still uses the legacy Symantec PKI system. The result of fraudulent certificates forced any site owner with legacy Symantec keys to order news ones and install the latest certificate on the web server.

Because the PKI system relies on trust, the aforementioned incident had a huge impact on the cyber security community. Had Google security researchers never caught the incident, sites hosting malware and phishing content using these certificates could have impacted millions of users that think they are communicating with an official Google domain.

REMME’s Solution to the PKI Problem

REMME’s solution is to use blockchain technology to remove the single point of failure — Certificate Authorities. Instead of implicit trust on a third party with no transparency, REMME builds a network of trust by providing a decentralized distribution of keys. By decentralizing key distribution, a central trust authority is turned into trust by computation.

By removing a central authority, the revised PKI system offers:

  • Transparency of who was assigned a digital certificate
  • Revoked certificates are instant
  • Extension of certificates are logged by a public ledger
  • New certificates issued can be verified and tracked on a public ledger

Any fraudulent certificates would be immediately rejected, and the Internet no longer relies on a single entity. The trusted environment restores the integrity of PKI systems and ensures that certificates can be audited by anyone including a standard user to a security researcher. By removing dependency on a CA, cyber security across the Internet is improved.

The actual development process can be checked in the dev branch.

Releases are for significant functionality changes only.

REMME’s official links:

--

--