ADKs (was: Corporate use of gnupg)

[David Shaw]

On Tue, Feb 19, 2008 at 02:54:07PM +0000, Nicholas Cole wrote:
> On Tue, Feb 19, 2008 at 1:23 PM, David Picón Álvarez
> <david at miradoiro.com> wrote:
> > > I know that ADK can be circumvented by a determined attacker, but it
> >  > strikes me as a useful feature, and I have never quite understood the
> >  > opposition to it.  It would have made encryption more palatable in
> >  > corporate settings, which surely would have been a good thing!
> >
> >  IMO there are two possibilities: 1) your users are forgetful but honest, 2)
> >  your users are dishonest.
> >
> >  For case 1, an equivalent of ADK can be obtained with a line on GPG's
> >  configuration file.
> >
> >  For case 2, you are screwed, and ADK is only going to give you a false sense
> >  of security.
> >
> >  Thus ADK is either pointless or unnecessary.
> 
> This just simply isn't true.
> 
> Putting a line in a config file may be fine for internal mail, but
> does nothing to help you to be able to decrypt mail sent from outside
> your organisation.  It also locks everyone into using gpg - I thought
> the whole point of gpg / opengpg was to be inter-operative.

Let's define some terms, so we're all talking about the same thing in
the same way.

An ADK, for "Additional Decryption Key", sometimes called ARR for
"Additional Recipient Request", is a packet that is added to a key.
It is hashed into the key self-signature, so the key itself is needed
to add it.  This implies acceptance (or at least knowledge) of the
existence of the packet by the key owner, and if nothing else, they
can simply look at the key to see the ADK is there.  (There was a bug
a few years back where PGP accepted ADKs that weren't part of the
self-signature, but that has been fixed).

The main point of an ADK is to allow companies to get the benefit of
encryption, but help avoid the big risk of an employee encrypting
something in such a way that the company can't get it back.  The
employee could encrypt it and then quit (either maliciously or
coincidentally), or encrypt it and lose their key, and so on.  It's a
real risk.

The ADK contains two pieces of data: First, a key fingerprint.  This
is the key that the key owner is asking you to also encrypt to.
Secondly, there is a bunch of flags that tell you how strongly the key
owner feels about this.  The key owner can say either "Please also
encrypt to this key" or "You MUST also encrypt to this key".  In use,
an ADK is just another recipient.  It's more or less equivalent to
automatically adding a "-r the-adk-key" to a GPG command line.

Finally, note that the ADK is *not* part of OpenPGP.  It is a
proprietary extension of the PGP product.  It is also patented, which
prevents those other than PGP from implementing it.  (The PGP folks
are actually very reasonable about interoperability issues, but as far
as I know, nobody has asked about this.)

Now, in a closed environment (say, internal email) where everyone is
using PGP, it's great.  Every message is also encrypted to the ADK
key, and the company has assurance they won't lose any critical data.
In a mixed (PGP + GPG) but still closed environment, it's still pretty
good: those people using PGP will follow the ADK, and those people
using something else won't.  In the case of disaster, some data will
potentially not be recoverable.  This can be handled via the
"encrypt-to the-adk-key" in gpg.conf method.

To be sure, an employee in this closed environment could hack up
something that doesn't respect the ADK.  That's not a problem with the
software.  That's a problem with the employee.

The more difficult case is a completely open environment (say, email
for a company that also wants to encrypt their external email).  In
this case, those people using PGP will use the ADK, and others won't.
It's not possible to require every external person to do what you want
(they don't work for the company and have no reason to follow the
ADK).  In these cases, there isn't much that can be done aside from
key escrow, or running some sort of mail gateway system that can be
the keeper of the secret keys, or possibly even bounce messages back
that don't have an ADK (eg "You won't use the ADK, so I'm not talking
to you").

> But my real point is this: gpg in most areas says "This is a tool.
> Your threat models will vary, and we give you a tool which you can
> deploy".  But in the area of ADK, even when for years people have said
> on this list and elsewhere, "ADK would help with the
> threat/organizational model we have", GPG refuses to help.  "alter
> your config file" solves (at best) half of the problem.

Even if the patent issue was resolved, it doesn't really solve much to
have GPG follow the ADK.  GPG is distributed as source - easy enough
for someone to simply comment out the ADK code if they didn't want it
to take effect.

David