Researchers honored for communications protocol

Photo by David Kelly Crow

A system developed by Princeton researchers that allows users to better secure the encryption of their electronic communications, rather than trust their providers to do so, has been recognized with a top prize at this year’s Privacy Enhancing Technologies Symposium.

The system, called CONIKS, allows users to transparently use encryption while ensuring that no unauthorized users breach the privacy safeguards. Developed in 2015, the technology received the Caspar Bowden Award at the symposium in Minneapolis on July 20.

The CONIKS system builds on a popular encryption system called public key encryption. In this method, users are issued two different long strings of numbers or characters called keys. One, called a public key, is used to encrypt messages sent to an individual user. The second type of key, the private key, is kept by an individual user. The private key is used to decrypt communications that were encrypted with the user’s public key.  One way to think of the system is to imagine the public key as a postal box address, and the private key as the box’s key.  Anybody can send messages to the address, but only the holder of the key can open the post-office box.

The system is effective, but it is also complex: private keys need to be kept secret, while public keys need to be widely distributed and accurately matched with senders and recipients.

Discovering another user’s public key in a trustworthy manner has always been the biggest problem for these systems.  Most popular email providers don’t support such strong encryption natively, and few users set up encryption and manage their keys.

“Even the somewhat technical user, let alone the lay person, has trouble understanding how to exactly make this work,” said Michael Freedman, a computer science professor who led the CONIKS project.

To improve upon this situation, instant messaging companies today often handle public keys, and automatically send them to anyone attempting to message a person on their system.

CONIKS gives users an option besides managing keys themselves or relying on their communications providers. Although there are not many known instances of providers having their users’ keys compromised, the researchers noted that even companies with the best intentions could conceivably be breached or forced to turn over keys by courts. So CONIKS is designed to take advantage of communication providers managing keys, while still making it impossible for the provider to read the contents of a user’s messages or mismanage public keys without the user learning of a security breach.

“We wanted to design a service where users could still maintain trust in the system even if there were hackers or government coercion,” said Marcela Melara, a doctoral student in computer science and the lead CONIKS developer.

With CONIKS, users store private keys on their own devices, like smartphones or laptops. A communications provider that adopts CONIKS would follow the system’s protocols for how to manage public keys. The details are technical, but at the broad level, the provider would create a publicly available declaration of all public keys it holds. The declaration does not include the keys themselves, but is a way for CONIKS to automatically check that no key has been altered by the provider. When any device using CONIKS connects to the provider, it would automatically verify that the declaration is correct. If the declaration is incorrect, CONIKS would automatically notify the user that their communications was insecure.

The system is designed to prevent “man-in-the-middle” attacks, in which an adversary provides a fake public key in order to intercept an encrypted message. The attack can happen when user A is trying to send an encrypted message to user B.  As usual, user A’s smartphone first requests user B’s public key from B’s provider in order to encrypt the message. But instead of returning user B’s public key, the provider (or even a third party in the worst case) gives a fake public key to user A’s smartphone; the phone then uses the fake key to encrypt the message.  Because the provider controls the fake key, the provider can decrypt the message and read the contents; the provider then re-encrypts the message with user B’s real public key and sends it along to user B. No one is the wiser.

Because CONIKS is a protocol rather than a service, any communications provider can adopt it for their system. The CONIKS protocol helped shape Google’s recent Key Transparency program, which built on the CONIKS set-up of allowing communication apps to verify their public keys.  The researchers have worked with several other companies, including Apple and Yahoo, to investigate for how CONIKS might work with their services. The researchers are also working with developers at the Tor Project and a few European universities to develop their own CONIKS implementation, geared towards smaller, security-conscious services like Tor Messenger.

The researchers chose to focus on building a key management system instead of a communication service because they found that the real obstacles to encrypted communications lay in how keys were handled, not how the encryption itself was performed. The math for encrypting and decrypting the actual contents of a message through the use of public-key cryptography has been well understood for years, Freedman said; the hard part was figuring out how to handle those keys—how to protect them and make sure they were provided accurately to anyone who wanted to send an encrypted message.

As the researchers work towards implementing the system for actual communications services, there are several questions they are still working through. For instance: what happens if someone loses the devices their private keys are stored on? With encrypted data, losing a private key causes the user to lose access to all past encrypted communications. Unlike most email users today, CONIKS users wouldn’t have an email service provider that can help them recover those lost keys. But ideally, CONIKS could allow users some flexibility to make those decisions for themselves.

“If you have three devices and you lose them all, are you out of luck? Or do we want to give you a way to recover it?” Freedman asked. “Maybe you want to store an encrypted copy of your key on some third-party service, like Dropbox, or maybe you think that makes it less secure. CONIKS could allow you to make that decision yourself.”

In addition to Freedman and Melara, the researchers on the project included: Aaron Blankstein, a recent PhD graduate in computer science; Joseph Bonneau, a former Princeton post-doctoral researcher, now an assistant professor of computer science at NYU; and Edward Felten, a computer science professor and director of the Center for Information Technology Policy.