Clarifications on PGP5 'vulnerabilities'
On Mon, Feb 09, 1998 at 10:57:15PM +0100, Martin Schulze wrote:
> > The release of PGP 5.5 Business contains Company Message Recovery
> > (CMR). Even release 5.0 supports CMR. What is CMR you might ask?
> > It's similar to key recovery. You're sending an encrypted message
> > and without your knowledge it's encrypted with a third key so your
> > boss (or the government) may read it, too. Nifty feature, right?
>
> Stop the FUD. That is an _optional_ feature, if you want
> you can enable it -- if you don't, then _don't_.
Stop here, guys. (And try to read my bad English)
You are looking for a single line of code enabling third party access to any
PGP message generated in past and future. Obviously such a line does not
exist. The problem is much more complex.
Problem description:
In USA employee privacy does not exist. Germany (and other European
countries) have laws to protect even the privacy of employees, its
called datenschutz. Datenschutz means, that you have the right to limit
the collection, use and distribution of any data related to your person.
It's common to American companies to trap and record all incoming and
outgoing phone calls. So there arises the natural need to reimplement
this behavior for encrypted mail, too. In Germany such a practice is
forbitten by law.
PGP Inc. developed PGP5.any to fit this needs. Despite the common practice
a completely other technology is needed by companies: They need access to
stored data in users mailfolders not to communication data in transit. The
CMR approach enables a wide field of espionage activities. OpenPGP solves
this problem by introducing a key usage with a appropriate semantic.
The PGP5 approach in detail:
PGP5 allows to construct a certain area, where every encrypted mail crossing
the border can be read by a third party associated to this area.
To ensure this third party snooping PGP5 uses three features:
- The ViaCrypt Code: All outgoing mail is automatically encrypted to
the third party key. This is a configuration option. (PGP5.0 has this
code disabled)
- The CMR Code: All public keys contain a ARR (Addition recipient record)
mandating (or suggesting) addition encryption to the third party key.
The third party key is called MRK (Message recovery key).
(PGP 5.0 has this code enable, but assumes all ARR to be mandantory)
- The Policy Enforcer: It bounces all encrypted mail which is unreadable
by the thirt party.
If the addition encryption would not be automated, the policy enforcer would
fail to work, because a lot of email would be lost. So the policy enforcer
only prevent active attacks (deleting the MRK from the window...)
Consequences of the CMR (Company message recovery):
Obviously CMR is not limited to Companies. It is simple to introduce GAK
using this system:
- A gouvernment waits until PGP5.any is widespread enough.
- The generate a hype of unsolved criminal cases, in which the innocent
recipient of a message of criminal content can't defeat the abuse of
police officers.
So the gouvernment recomment to include the police key as ARR. This
allows to read incoming mail, not outgoing. So the user will not be
subject of an hidden investigation, because his mails are unreadable.
- Some years later a second press hype shows, that over 98% of all
citizens follows the recommendation, but a few criminals does not.
So the set up a law requiring policy enforcers on all ISPs.
Nobody will cry on this schedule, because only a few hundert of people are
harmed to change there behavior at a given time.
Furthermore industrial espionage has a new and very silent tool to work
with. I got several phone calls of international companies dealing with
this problem and avioding PGP5 as much as possible.
The OpenPGP approach:
The IETF mailinglist came up with the following idea:
8 - key usage (REQUIRED)
It is an octet used as a bit field. This is found on a self-signature.
+---------------+
|7 6 5 4 3 2 1 0|
+---------------+
Bit 0: certification of other key/user ID bindings.
Bit 1: signing external data.
Bit 2: encrypt external data for communication.
Bit 3: encrypt external data for storage.
Bit 7: key is a group key, multiple persons can use it.
If this field is missing, this field is assumed to be 0x07
(certifying, signing, and encypting communication). If a primary key
is followed by subkeys, the key usage of the primary key is assumed to
be 0x03 (certifying and signing) while the key usage of the subkeys is
assumed to be 0x04 (encypting communication).
Storage keys MUST NOT be used in communication. They SHOULD be droped
from keyrings outside the desired storage enviroment to avoid message
key recovery. They MUST NOT occur on public keyservers. If such a key
arrives over the Internet, a warning MUST be produced and the key MUST
be droped (prefered) or disabled locally.
Group keys for communication encryption may be set up by a company to
address encrypt company readable e-mail to. Software MUST produce a
warning, if a group key is used. Group keys are for encryption of
communication only. Keys combining an other purpose to a group key
MUST NOT be generated and MUST NOT be accepted.
The same key usage subpacket MUST occur on every self-signature
certificate. If other user IDs specify a different key usage, the key
MUST be disabled.
Furthermore it handles the ARR correctly:
10 - symmetric key recovery key (REQUIRED)
This option consits of a class octet, a asymmetric cryptosystem
identifier octet, and twenty octets of the fingerprint. The last eight
octets are the key ID. So only keys of the packet format four or
higher can be used. This is found on a self-signature.
The class octet is one, if the use of this recovery key is required.
If it is zero, the use of this recovery key is up to the user. If data
is encrypted to such a key, it MUST/MAY (depending on the class octet)
be encrypted to each recovery key, too.
Keys containing this subpacket are local storage keys only. They MUST
NOT be used in communication. They SHOULD be droped from keyrings
outside the desired storage enviroment to avoid message key recovery.
They MUST NOT occur on public keyservers. If such a key arrives over
the Internet, a warning MUST be produced and the key MUST be droped
(prefered) or disabled locally.
Both ideas are defeated by the current editor of the verbal draft (Jon
Callas, Senior Security Architect of PGP Inc.) The current version reads:
Additional recipient request (1 octet of class, 1 octet of algid,
20 octets of fingerprint) (Hashed)
Key holder requests encryption to additional recipient when data is
encrypted to this username. If the class octet contains 0x80, then the
key holder strongly requests that the additional recipient be added to an
encryption. Implementing software may treat this subpacket in any way it
sees fit. This is found only on a self-signature.
There is formal OpenPGP draft which is going to define the semantics of this
field to (translated to a more readable form):
If the subpacket exists, the key SHOULD be droped, keyservers MUST NOT
accept the key. If a user likes to respond he MUST get a warning and MAY
choose from one of the following options:
- Ignore the request (default/MUST, if no user interaction)
- Fake a session key matching the IV and padding tests of the
policy enforcer (which is possible *evil grin*)
- Use it as requested.
HTH
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: