Trusting Government IDs in the Web of Trust

Generally-accepted practice for verifying the identity of other cryptography users and extending your web of trust to them usually involves checking a government-issued photo ID, verifying that the picture is the person giving you the key fingerprint, and then verifying that the name on the ID matches the name on the PGP key that you are going to sign. The purpose of this is to know that, when you encrypt to that key, only the person you think is receiving the mail can read it, and that signatures from that key come from the person who claims to use it. It allows you to associate the cryptographic key with a person.

In the present era, where state-level adversaries are on the top of many security-conscious users’ minds, isn’t this a hole? Aren’t we depending, critically, on the very entity we are trying to protect ourselves from?

I don’t think this is a significant weakness, though. To understand why, let’s first consider exactly what attacks would be enabled by the government misusing its identity-certifying authority. It allows them to compromise key exchanges. That is it. Specifically, if Alice and Bob want to exchange key fingerprints, what Proconsul Eve can do by forging an identity document is to substitute her operative Albert, with government-issued documents certifying he is Alice, at the meeting. The result is that Bob will have thought he verified that Alice’s key actually belongs to Alice, when in reality the private key is held by Eve. So when he talks to Alice, he’s really talking to Eve.

Once the key exchange is done, however, Alice and Bob have no need for government-issued ID. They have securely exchanged keys, and Eve cannot fake an exchange to substitute her own keys. The only thing that can be done by issuing an invalid ID card is to compromise the initial key exchange.

In order for this to work, many things have to happen:

1. Eve must known, in advance, that she wants to impersonate Alice to Bob. She cannot decide after Alice and Bob have verified keys that she wants to interject herself; Alice must already be a target.
2. Eve and Albert must know when and where the key exchange is to take place, or proactively arrange to exchange keys with Bob.
3. Alice can’t be tipped off.
4. Albert must be able to pass for Alice. If Alice and Bob have never met, he might be able to do this. But if Alice and Bob have met, Bob may know something is wrong. Even if they have only met digitally, there may be conversational patterns and shared knowledge that can tip Bob off. Further, if Alice is a known person, Bob may have seen her picture, etc. Any of these things may tip Bob off that something is not right, and lead him to terminate the exchange.
5. Alice must be sufficiently new to the Web of Trust that her encryption keys are not already known to others. As soon as Bob finds there are two keys claiming to be Alice, he can get suspicious; if his contact Carol has signed Alice’s other key, then he has good reason to believe something is wrong. Even if he has the right key and Eve has duped Carol, they know they need to stop and reassess. There are some subtleties here with established users generating new keys, but those do not seriously complicate the analysis.

So: for state-sponsored impersonation to be useful, they must know who they want to target before the target has made significant use of encryption.¹ But if you (or your contact) is likely to attract that kind of attention prior to establishing secure communication channels, you have a lot bigger problems than whether you can trust the government-issued ID. And there are other ways you can go about establishing identity that bypass this problem (most obviously, having a mutually-known third party make an introduction).

If Eve wants to intercept Alice’s communications with Bob, there are far easier ways to do so that don’t require such specific circumstances. Eve can deploy targeted malware, acoustic cryptanalysis, or rubber-hose cryptanalysis, just to name a few techniques that are effective and don’t have as high a risk of Bob perceiving something to be amiss.

So to summarize: given the risks, special requirements, and low benefit, using false identity papers to intercept or stage a key exchange seems like an unlikely attack vector for a state-level adversary to employ, especially with the ready availability of superior methods of achieving the desired ends. Further, an ordinary adversary forging a government ID seems like a more relevant risk than a government issuing a false ID. And finally, truly defending yourself against a state-level adversary depends on a lot more than a successful key exchange. If you can solve the other opsec difficulties involved in such a life, you should be able to find a way to do a reliable key exchange should you need it.

I do not have a problem, at present, using identity papers issued by stable governments as a means of verifying identity for the purposes of common key exchange.

No comments on this site, but if I’m missing something, please do let me know.