Fixing the NONE_SDH_M security hole

Bill Frantz
Thu, 08 Oct 1998 11:35:49 -0700

The triage of priorities in Electric Communities's (EC) rush to get product
to market resulted in exportability winning over security.  This resolution
is marginally acceptable for the short term since:

  (1) EC is making NO security claims for the product.
  (2) With authentication, the product is more secure than competitors.

However, for the long term, I think EC would like to make stronger security
claims, and I also think the open E community would like a freely
exportable version.  To get there from where we are, we need to patch the
security hole.

The security hole this change opens is that the swiss numbers are no longer
protected from evesdropping.  They are sent in the clear.  If we encrypt
them, but not the other information, then we are using cryptography for
authentication, but not privacy, which is still freely exportable.  (I
thank Tim Oren for this idea.)

To fix this problem in Proxy comm, I suggest the following:

Introduce two stream cyphers (one for each direction) available to users of
the DataConnection.  These stream cyphers would be keyed by the same Diffie
Hellman interchange which is used to set up the symmetric authentication
keys.  The API would be two methods:

   public void getEncryptMask(byte[] mask);
   public void getDecryptMask(byte[] mask);

In both cases, the mask array is set to the next output of the stream
cypher.  The way these methods are used is as follows:

To encrypt swiss numbers:  In the same unit of operation as the message is
sent, which means that multi-threaded implementations must be synchronized
on the Vat lock for the vat DataComm is using, call getEncryptMask, XOR the
mask with the swiss number, and send the message.

To decrypt swiss numbers:  While executing the processMessage() method in
the MsgHandler, call getDecryptMask and XOR it with the swiss number.  If
there is more than one swiss number in a message, they must be decrypted in
the same order as they were encrypted.

My current thought is to use Arc4 (a stream cypher by Ron Rivest with a
remarkable similarity to RSADSI's tradmarked and trade secret RC4 cypher)
as the stream cypher.