In message <[EMAIL PROTECTED]>, John Denker writes:
Here's a challenge directly relevant to this group:  Can you
design a comsec system so that pressure against a code clerk
will not do unbounded damage?  What about pressure against a
comsec system designer?

If I understand your question correctly, in 1994 a VPN product was fielded that had this capability. It did not have any capability for static group or tunnel keys. It was only RSA/DH using DH for the tunnel key and RSA only for authentication. The device had "perfect forward secrecy" because the use of RSA disclosed nothing about the tunnel keys, and complete RSA secret disclosure would only divulge that the D-H was authentic. The DH private keys were use once random and the public parameters, well, public. The user could set the tunnel lifetime short or long, their choice.


In this case, the "code clerk" had no direct access to the key material and could not set static keys even if they tried. The box was not tamper resistant, but it was not easy to remove the keys even with physical access.

The device did not have a "group password" (current Cisco IPSEC vulnerability) and used an invitation scheme to bring new nodes in. Link to Cisco notice is here http://tinyurl.com/6jovo

Once the system was fielded, pressure on the systems designer could not change this.

In essence, there was no code clerk. One can argue that the network administrator is the code clerk, but that person could still wire around the VPN device or attach a completely separate backdoor to to cause, as you say, "unbounded damage" in a way that does not compromise the comsec system.

This was one of the original proposals for IPSEC, but was not selected (but that is another story). Subsequent generations of this device are still being built and sold from http://www.blueridgenetworks.com/

So, as long as I have understood your question, such systems have existed for some time.


--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to