Philip Sugg

A New Paradigm for Consumer Security

Portfolio-Home

The widely known “three authentication factors” principle says that online security can be divided into the following categories: (1) something you know, (2) something you have, and (3) something you are.

“Something you know” is what most everyone uses on the internet uses to secure his or her online identity: a password, or variants like PIN numbers. “Something you have” is any object or possession that certifies you are who you say you are (e.g., an identity badge that workers use to scan into a building). “Something you are” is often an unchangeable quality of a person, like a fingerprint or a facial scan.

While all of three methods are valuable and appropriate in certain settings, it is still the case that the most visible and widely-used form of security for end users is the first option, “something you know:” a password. This despite ever-increasing attention to hacking-based vulnerabilities against passwords (“spearphishing,” etc.), billions of dollars spent on password managers to make them more usable and secure, and evidence that the average is still unable to create and use password-based security effectively.

In response to the ongoing inadequacy of passwords and the “something you know” approach to security online, this guide is about a different, complementary, increasingly viable method of going about security: not “something you know” but “something you have:” public key encryption.

Only a minority of technically adept users are likely to recognize the term. For anyone who has experience writing code, typing at the command line, or working on a remote server, the technology may be familiar. But most people have not done any of these things, and while most of us still use public key technology to browse the modern web securely (using HTTPS) and communicate over certain secure messaging platforms (e.g., the Signal protocol), public keys are not a user-facing technology in that setting.

But while it is possible to automate public key security, the purpose of this guide is to offer a practical, hands-on education to users who want to actively use it. Public key encryption is a lot more than just a better version of a password: it is an entire toolset that has an open-ended set of uses: from securely authenticating with services on the open internet, to offering a proof of identity, to exchanging secure messages with others over email, to private encryption of sensitive files and folders. Compared to passwords, public keys are resilient in the face of hacking and breaches, and more decentralized in their typical implementations. Consumers have the potential to exert greater control over their data.

Advantages of Public Keys

Passwords are single-point-of-failure systems. Since a password–or a version of a password–is stored securely on both the client and server, stealing from either source is often sufficient to gain access to a user’s account. Public key systems do not work this way. You can think of public keys as very secure passwords, in which the client and server have different versions of the same password. Stealing one does not get you the other.

Public keys are called “public” because they are meant to be shared–in essence, they are impossible to steal–and they come as part of the a two-“key” set. To log in, a client uses the other key in the set, a “private” key, which is used to authenticate actually with the other party (e.g., a communication partner, a cryptographic program, a server).

Password-based security always depends, to a large extent, on the user’s willingness to learn and practice good password conduct. By contrast, a public key system requires a key that is produced correctly; high standards are baked into the algorithm for both producing and using the key. While user error is still possible, good security practices like the length of password, and the extent to which it is shared, are enforced by the cryptographic algorithm itself. In short, algorithms take control of the most security-critical steps of the process of verification, while the user remains in control of where to implement a public key system.

Public keys are versatile and can take many forms, from a piece of hardware the user physically controls, to a component built into any software behind the scenes. Public key security can be implemented at different levels of trust and security depending on the situation. It can even be used alongside passwords; one of the most likely ways for the average user to encounter public keys is as a “second factor,” an additional step after the password has been accepted. Because public keys are flexible, new use cases continue to develop. The point is that public keys can take the form that the situation dictates: they can hands-on, technical and highly configurable for some users, but also silent, automatic, and zero-user-input in other cases.

What is a Public Key?

But before we go any further, this note has so far spoken about “public keys” without explaining what that technology actually is. While public key cryptography can be easy to use, the technology can be tricky to explain conceptually without wading into technical detail.

From the functional perspective, you can think of public key security as a set of at least two long passwords that are tied together by an encryption algorithm. One big difference between public key encryption and passwords is that you never get to choose your key: instead the user chooses the method to generate keys. Here are the first few characters of a sample public key generated using the common RSA algorithm:

AAAAB3NzaC1yc2EAAAADAQABAAA...

…and so on for hundreds more characters. For a user, that’s all the public key really is.

Since all public key systems involve at least two corresponding keys, each time you generate a public key, you also create a corresponding private key. Let’s look at an example. There is no way to tell by looking that the two keys are related. The first characters of the corresponding private key for the above public key are this:

b3BlbnNzaC1rZXktdjEAAAAABG5vbm...

…again, hundreds of seemingly random characters (in reality they are anything but random).

Both keys resemble passwords created by a good password manager, but they differ completely in how you use them. A public key is just a password that is meant to be shared (the system in fact requires it). You can freely share the public key because it has no value as a method of compromise. It doesn’t provide enough information to authenticate you, encrypt anything, or otherwise function as a security tool– a public key is well and truly useless without its companion private key. The purpose of the public key is to create a record for a counterparty, so that when a user appears with a corresponding private key, that counterparty can determine whether he or she is authorized to access the record in question.

The public key becomes actionable when it is tied to its corresponding private key. If I give you, the server, my public key, and then come along a few days later and present you with my private key for that same key pair, my private key confirms that I am who I say I am (note that public key encryption does not require that I actually exchange my private key with the server to confirm this). One of the features of a public key set is that there is no way to figure out what one key is supposed to be, given the other. So if I show you my public key, there is no practical way my private key from my public key. Matching keys are generated at the same time, and only then. What the algorithm does that compares them is to verify that the two keys are, in fact, necessary companions to one another.

This is such a powerful system because it offers no shortcuts to proving a person’s identity. The fact that they keys are not the same means that each is targeted to the specific role it plays. One key, the private key, thwarts hackers by design–because it is already shared. The other key, the private key, is designed by a reverse principle: it is always private, and there is no situation in which it needs to be shared during authentication, encryption, and other operations. Unlike passwords, the public key system does not require users to share private keys in order to use them. Because the private key is always held in secret, it can be kept in an extra-secure location, like on a restricted parts of the user’s hard drive, on a hardware token, an ID badge, or in other locations where even an actor who intends to steal it cannot find it.

Broad Industry Support for Consumer Adoption of Public Keys

The consensus across major technology companies is that passwords are fundamentally flawed as a primary means of security, and that over the long term the paradigm needs to shift. Major players in the tech industry have concluded that public key systems need to be a major plank of next-generation security.

Google announced in a 2021 blog post that it wants to move toward a “passwordless” model across many of its services¹ Among the most prominent alternatives they envision are hardware security keys, which use a version of public key encryption.

Also in 2021, Microsoft created a passwordless option across its apps and services. Among the allowed alternatives were hardware devices backed by public key encryption.

One of the largest manufacturers of hardware keys built upon public key encryption, Yubico, operates atop a public key protocol called FIDO that allows users to login to select web platforms without a password.

There are also a number of independent movements backed by the major tech companies to bring public key encryption to widespread adoption. See, for example, the WebAuthn open standard, backed by Google, Mozilla, Microsoft, Yubico, that aims to allow “servers to register and authenticate users using public key cryptography instead of a password.”

Public key-based security is growing in prominence, and promises to be a major component of online life in the next several decades.

Closing: Three Ways of Thinking About Public Keys

This guide offers a set of related how-tos, glossaries, tutorials, and conceptual overviews of different components in the consumer public key landscape. It is intended to be a living document that adds more use cases as the technology matures. Depending on the use cases, the intended audience ranges from non-technical consumers who use hardware keys, cryptocurrency enthusiasts, and software developers who need a more robust way to secure a development machine. The public keys available to the public fall into three broad categories:

1. Public keys can be instantiated in physical hardware that the user presents when asked to authenticate

Prominent manufacturers of hardware keys include Yubico, Thetis, Kensington, and those designed and sold by tech companies like Google. Holders of cryptocurrencies will also be familiar with a “crypto wallet,” which contain a private key that gives access to a virtual currency. The Department of Defense operates its own authentication system called the “Public Key Infrastructure”, which, among other functions, implements a public key systems on physical access tokens (keys, ID badges).

The most important action the ordinary user can take with respect to hardware-based public key devices is to use them. The technology is mature enough that it is now suitable for quick daily use. However, many hardware keys are capable of far more functionality than simply providing a primary or secondary authentication factor when logging into a website.

2. Public keys can be recorded in software

Public keys can also be implemented purely in software. As I mentioned above, the most basic version of a public key is just a long string of characters in a rudimentary text file. What is important about a software public key is that it has stable features which are meaningful to a user. Some of the most common public key implementations contain predictable, unchanging metadata like a “fingerprint” (a unique identifier for that key), individually identifying information (e.g., email, first and last names), dates of expiration, and information about the algorithm that created the key. Any owner of a software public-private keyset should be comfortable with these characteristics and understand how to manage them. The goal of this guide is to explain some of the most common use cases for software public key encryption. These will include topics like GPG encryption for email, hardware keys for logging onto any number of major online services (with more added each day), and digital wallets, which give the user direct control over his or her funds, thereby avoiding centralized “hosted wallet” services and their potential security risks.

3. Public keys are already essential infrastructure, used by nearly everyone on the internet today

Whether or not you have any interest in learning more about public key security, the technology is already built into foundational protocols on the modern internet. Public key encryption is woven into tasks like providing a secure login, offering proof of identity, and processing secure payments. For example, HTTPS protocol, now near-universally adopted among most sites on the internet, is what ensures secure communication between the web server and client (user) on the internet. This is what allows a user to be sure that when she enters her bank credentials into an online form, those credentials will not be intercepted by third parties. And it uses a form of public key encryption known as “Transport Layer Security” (TLS). Since so much of what qualifies as infrastructure on the internet is beyond the user’s awareness and control, this guide will also empower the use to make better choices online. For example, by switching chat apps to a platform with stronger standards of secrecy, or by knowing how to interpret an expired security certificate on a website.

Permalink