[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network Layer Encryption History and Prior Art


        As one who participated somewhat more directly in the history of
this, let me refine some of Paul's comments.  The first packet encryptor
was the PLI (not IPLI) developed in the early 70s by BBN under DARPA
funding.  It was approved by NSA for limited deployment on the ARPANET, to
protect classified data being sent by DoD folks, starting in 1975 (a
somewhat more sophisticated version was approved for use in 1976).  Due to
the restrictions imposed by use of government COMSEC equipment (KG-34),
this was a manually keyed system.

        In the 1975-1980 timeframe, BBN and the Collins Radio division or
Rockwell developed and did limited deployment of the BCR, also under DARPA
funding, as an experimental network encryption device. The BCR worked in
the TCP/IP protocol environment, used the first NBS-certified DES chips,
and had automated, KDC-based key management and access control (the same
model later adopted by Kerberos and Blacker).  The BCR underwent
substabtial performance testing in 1980-81, before being retired.  Later,
DES-based network security devices were design and some were built as
prototypes for DARPA in the early 80s, experimentin with higher speed
network connections (Ethernet) and newer versions of protocols (IPv4 vs.

        The first Blacker program also began in the late 70's, funded by
NSA with work done by SDC (software) and Burroughs (hardware).  It too made
use of centralized key management and access control. The followon program,
designed to produce a product (vs. a proof-of-concept demo) was awarded to
Unisys (merged SDC and Burroughs) in the early 80s, but it did not produce
fielded devices until the late 80s.  The fielded Blacker was revolutionary
in its use of a single processor design with the (custom) crypto as a
peripheral on the internal bus.  It was designed to be a very high
assurance (A1) system.

        In the early-80s, BBN developed the IPLI, a successor to the PLI,
updated to use TCP/IP, newer COMSEC technology (KG-84), but still manually
keyed.  The IPLI was a backup program, funded by DARPA and DCA, in case the
more ambitious (multi-level secure) Blacker program was delayed (which it
was) and caused programmatic problems for the newly inaugrated Defense Data
Network (DDN).  IPLIs also were deisgned for a tactical environment, for
use with DARPA low caost packet radios.  A small number of IPLIs were
delivered in the mid-80s, but never saw real deployment.

        All of the devices described above embody the essential network
security designs that later were elaborated and improved upon in the SDNS
program.  However, none of them supported selective encryption on a
per-packet basis, i.e., they all assumed that every packet emitted by a
host or router on the "red" side of the device was to be encrypted.

        The CANEWARE program evolved from the initial, pre-production
Blacker work in the late 70s, when one of the projects was a multiplexed
link encryptor.  Motorola was the contrtactor and the Air Force was the
primary client.  The client decided that muxed link crypto was not the wave
of the future and the program gradually evolved into a network encryption
project, called ENSNARE, by the early 80s.  ENSNARE was a traditional
approach to network crypto, completely analogous to the BCR, but using high
grade COMSEC chips designed explicitly for this purpose.  ENSNARE begat
CANEWARE in the mid-80s, and for a while CANEWARE became the preferred
backup for the long-awaited BLACKER product.  CANEWARE diverged from the
other programs by adopting the FIREFLY key management technology that
became a centerpiece of the SDNS program and later network security
efforts.  As CANEWARE continued, it adopted the SDNS protocols for IP layer
security and key management.  During the late-80s, the CANEWARE interface
spec began to include a capability for selective encryption, i.e., traffic
to selected host  addresses need not be encrypted.  To the best of my
knowledge, this was the first high grade network crypto device to include
such a capability. However, the first widely published paper on CANEWARE
(which appears in the proceedings of the 10th National Computer Security
Conference, 9/87), does not mention this facility.

        The SDNS program (1986-91) developed protocols for layers 3 & 4 and
for e-mail secruity and realtime key management.  It included the notion
that selective encryption could be employed (e.g., on an address-pair
basis).  I would check the SP3 specs sent to NIST in the late 80s for
reference to this particular facility, since that seems to be the critical

        In the late-80s, IEEE started the SILS program, to develop security
protocols for LANs.  It was oriented toward commercial (not just
government) clients and thus had a model that allowed for selective
encryption (and/or integrity protection) of packets.  In the proceedings of
the 12th National Computer Security Conference, 10/89, there is an overview
paper on SILS and that may make mention of what seems to be the relevent
feature.  Russ Housley was the co-chair of this committe for some time, so
he may have access to better/more citations that would point to this

        However, I did find what appears to be a relevent citation in
looking through the 13th National Computer Security Conference proceedings
(10/89).  In a paper entitled "Low Cost Outboard Cryptographic Support for
SILS and SP4" (B.J. Herbison, pages 286-295), there is explicit mention of
a selective encryption facility in the device designed by DEC (and later
built by them!).  On page 288 the paper notes "The device recognizes
several frame formats (both SILS and SP4) in frames passing through the
device and encrypts or decrypts parts of the frames.  if a frame doesn't
contain a recognized format, then the frame is passed through unmodfied."
In this design, software in the workstation or router or bridge decides
what will or will not be encrypted and encapsulates it as appropriate.
Then the simple crypto module does the necessary operations as directed by
the encapsulation protocol.  Thus, the combination of the software
executing on the attached device plus this simple, inline crypto module,
performs selective encryption/decryption of packets (viewed as MAC layer
frames by this device).