Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

On Strong Identity Management

Alice wants to send an encrypted message to Bob; she knows his address, but doesn’t know the public key that goes with that address. Using GPG, Alice would look up his address on a key server, the issue is of course that anyone can upload a key associated with Bob’s address.

Using the “web of trust” model, Alice would look at the different keys and see which ones are signed, and if any of them are signed by people she knows. The problem is that Alice doesn’t normally use GPG, and she hasn’t marked the keys of the people she knows as trusted (I expect this is true for most casual GPG users), thus, she can’t tell what key is signed by keys she should trust, versus the ones signed by keys she shouldn’t.

In years of effort, this is still an issue.

There are many issues with this model, especially when it comes to casual users that don’t understand the details of the “web of trust” – while GPG use is certainly going up thanks largely to the Snowden revelations, many of these users fit into the casual users group. Thanks to the complexities of the model, these users may not be getting the level of protection they think they are.

Here are just a few of these issues:

  • Lack of strong linking – there isn’t a strong, verifiable connection between a user’s address, and their public key.
  • Complex user interaction – to be useful, the user has to understand the web of trust model, and how to leverage it. Based on the discussions I’ve had with people who recently started using it, most don’t get it.
  • Key discovery – finding the right key can be a nightmare, especially for some people. When there are multiple “valid” keys published, each with signatures, it can be hard for novice users to figure out which one is right.

I could go on, but I think the point is clear – the web of trust works well for some users, but only the users that take the time to really understand it.


I’ve been drafting a specification for a secure messaging protocol called SMIMP, as far as I’m concerned the Identity Management component is the most important part. It’s what allows the rest to work – secure messaging isn’t that hard, key handling and validation is where end-user system start to fail.

To provide a strong identity management system, a few goals need to be met:

  • Strong link between address and public key.
  • Updates to identity information signed by the user to prevent unauthorized changes.
  • Provide a full history, including all changes from the time the account was created.
  • Use of a hash-chain to show that no changes have been removed.

The IM in SMIMP meets all of these. The suggested way of using the system is trust on first use, pinning on both the first and the most recent public key. It would also be wise for the user to validate the recipient’s current public key via a trusted channel on first use, but that’s something that rarely happens in practice.

To detect a malicious server, or modified traffic, the user’s client should first check to see if the original public key has changed – if it has, it indicates that the user’s information has been replaced in its entirety. Second, it should see if the most recent key is no longer listed in the user’s history – if its been removed, it indicates that the user’s history has been truncated, possibly in an attempt to encourage the use of a compromised key. These checks provide an easy way for client software to validate that keys can be trusted.

To make the system more useful, the SMIMP identity information includes more than just the public key (all of which are optional):

  • Name
  • Web site
  • List of social media profiles
  • Additional data (comments, or other data the user wishes to assert)

This provides a simple way to strongly tie addresses to public keys; thus making secure messaging easier and more understandable for casual / non-technical users. For a solution to be widely usable, it needs to be effective for everyone.

The best solution?

SMIMP may not be the best solution, and there are some things about it that I don’t care for myself – such as exposure of more metadata than I’d like. But, it is a solution to the issues surrounding email, and identity management.

The issues of email security can be fixed, and identity management is part of that problem. There has to be a way to tie a user to their public key in a more reliable manner than what we have today (and without resorting to the mandatory government ID idea that won’t die).

I encourage everyone to look at these issues, and think about possible solutions. Contribute to SMIMP or one of the other efforts to fix the issues around email; we can no longer ignore these issues. The community needs to find and implement solutions that assure the security and privacy of the global community.

Adam Caudill

Related Posts

  • SMIMP at the DEFCON Crypto Village

    Last week I gave a lighting talk at the DEFCON CryptoVillage on SMIMP. The talk went over the basics of why the project is needed, and how the specification works. Here are the slides: Here is a rough transcript of the talk: Slide 1: I’m Adam Caudill, I’m a developer and security researcher; I work on a number of different things, but my recent work has been around privacy and secure messaging.

  • The Sinking Ship of E-Mail Security

    E-Mail, the venerable old standard for internet text messages, dating back to the early 1980s – and back to the early 1970s in other forms, has long been the “killer app” of the internet. While so many companies try to make the next great thing that’ll capture users around the world – none of these compare to the success of e-mail. It is likely the single most entrenched application-layer protocol used today.

  • Security By Buzzword – Why I don’t support Ensafer

    Update: I had a call with Ensafer’s CTO, Trygve Hardersen to discuss the issues I brought up, and what they can do about it. First, they updated the site so that downloads are now over HTTPS. He stated that the infrastructure that powers their service is separate from the website, and everything is over HTTPS. They are working on making documentation available, and hope to have the first documents available soon.

  • Win by Building for Failure

    Systems fail; it doesn’t matter what the system is. Something will fail sooner or later. When you design a system, are you focused on the happy path, or are you building with the possibility of failure in mind? If you suffered a data breach tomorrow, what would the impact be? Does the system prevent loss by design, or does it just fall apart? Can you easily minimize loss and damage, or would an attacker have free rein once they get in?

  • On Apple, Privacy, and Device Control

    If you’ve bothered to look at Twitter or any technology news source, you’ve seen that Apple made a major announcement: Expanded Protections for Children. This has been written about by countless outlets, so I’ll assume you’re familiar with the basics. The announcement covered a few new features being added to the next version of Apple’s operating systems, namely: Scanning of inbound and outbound messages for sexually explicit images. Scanning images being uploaded to iCloud for CSAM.