Re: [PLUG] PGP ADK Vulnerability.

[Vik Bajaj <vbajaj@sas.upenn.edu>]

[I just noticed the need for:

PGP - pretty good privacy
NAI - Network Associates Inc.
PKI - Public Key Infrastructure
ADK - Additional Decryption Key
CA  - Certificate Authority
X.509 - PKI extensions to X.500 directory services
LDAP- Lightweight Directory Access Protocol
]

{

I think there are some terminology issues.  The PGP public key
certificate can include both a primary public key and any number of subkeys.
These subkeys reside in a nested field in one particular data structure
called a "signature packet."  The Version 4 signature packets allow for
these "subpacket fields" to be either hashed (i.e. cryptographically protected
and authenticity verified) or unhashed (i.e. completely unprotected).

Now, due to NAI's dubious engagement with the key recovery alliance, they
sought to provide a method to acheive the effects of key escrow in a
corporate message recovery environment without actually escrowing the
private key of every sender.  The solution they settled on was to add
an Additional Decryption Key (ADK) to each public key certificate wherever
CMR has to be enforced.  The PGP sender then encrypts his message to the
public key of both the intended recipient and the ADK;  both parties can
now uncover the ciphertext.

The problem is with the implementation of ADK.  The ADK reference resides 
in a type 10 subpacket of a Version 4 self-signature packet mentioned above.
Unfortunately, NAI PGP (and others) don't care if the ADK pointer is stored
in a hashed or non-hashed field.  So, a hostile user can insert arbitrary
ADKs into a public key certificate without affecting the validity of the
certificate.  The end-user would either have to manually verify that the
ADK is stored in a hashed field for each certificate or use some out-of-band
communications to address the problem.  

> It's important to note that the above advisory and "bug fix" only 
> addresses the (quite justified) concern that an ADK can be hacked out 
> of the PGP key.  

I am not sure exactly what you mean by "hacked out," because all the keys
involved are public.  Can you clarify?

> *not* correct the fact that the ADK exists.  

> It appears to me that an ADK could still be surruptitiously added to your 
> PGP key without your knowledge at creation time.

Yes, this the point of the advisory.  There is no need for the ADK to
be added at creation time.  Somebody could trivially distribute a valid
public key certificate containing a hostile ADK reference.  If the conditions
outlined in the advisory are met and the user confirms encryption to the ADK
as well as your public key, then a message will be send which is readable
by a third party.  I have verified Ralf's results in that matter.

> Could someone with a decent knowledge of encryption technology address this
> concern, please?

It's not as bad as it sounds, and in some cases worse.  If I'm having 
an affair and want to encrypt messages to my new girlfriend, then I would 
be pretty suspicious if the PKI sent me a certificate with an ADK.  If, on 
the other hand, I'm communicating with a client and get an ADK-containing 
certificate from his CA, then I'd never really know if the ADK is reasonable 
or not without manual inspection.  The patch addresses that problem by 
forcing the ADK into a hashed subfield.

The broader and bigger problem is in two areas.  The first is key escrow
and corporate message recovery.  Universal key escrow is a legislative
suggestion completely disconnected from realizable technical implementation,
so I won't even address that (unless someone is interested).  However,
CMR is often needed.  In my opinion, CMR should remain a function of the 
PKI/directory pair, and PGP, S/MIME, SSL and other certificates should
all be brought under X.509 wrappers and distributed with a proper CA, not
by some ad-hoc means.  The encryption engine should not be polluted to
the point where its source is beyond audit;  it's best to leave the business
policy to the directory services and PKI.

That said, do you want to trust your CA?  Last month, I found that
Netscape iPlanet default installation was open in a number of ways.  

Here at MIT, we are all issued personal browser certificates which allow
access to all kinds of services.  The initial key binding rests on the
security of the kerberos authentication backend, because you must be
logged into the Athena system to access the certificate server.  But,
the process itself is transparent.  I am trusting MIT, which is fine, because
MIT also runs all the services that I'm going to access with the certificate.
But, would you trust them if I was sending you encrypted mail with the
certificate?  

-V.















______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug