New encryption technology closes WLAN security loopholes

[John Gilmore]

> Any ipsec system takes care of the eavesdropping problem; the harder
> part is deciding how to do authorization.  If you're trying to keep
> the system open for public use, but also keep your intranet private,
> you've got a more complex problem.

The Linux FreeS/WAN ipsec implementation has been working on this
issue.  The fundamental problem is that as specified, IPSEC
requires manual setup of each tunnel at both ends.  If N parties all
want to communicate securely, this takes (N-1)**2 tunnels and
(N-1)**2 effort.

In the existing 1.91 release at www.freeswan.org, we added another
layer above the standard IPSEC (which continues to work and
interoperate fine).  This new "opportunistic encryption" layer delays
outgoing plaintext packets, and lets the IPSEC daemon look up their
destination in the DNS.  If it finds an authentication key there, the
daemon sets up an IPSEC tunnel to the destination, and redirects
the plaintext down that tunnel.  If it finds no authentication key, it
just forwards on the plaintext packet in the clear.  Thus it takes
advantage of 'opportunities to encrypt' while not impeding
communication with unencrypted endpoints.

This reduces the work of securing N sites to a factor of N (each site
needs to publish its authentication key and install the opportunistic
software), rather than (N-1)**2.  The software sets up whatever subset
is active of the (N-1)**2 tunnels, automatically.  This not only makes
IPSEC administration scale to the size of the Internet, but also
introduces the 'fax effect' which encourages newcomers to adopt the
same method because it means they can talk securely and effortlessly
with an existing and growing population.

This software is working well in testbeds, and the support will
continue to be improved in upcoming software releases.  The protocol is
documented in an Internet-Draft.  Both the software and the I-D are
available at http://www.freeswan.org .

This method protects us today against passive attacks.  As Secure DNS
is more widely deployed and operated, it will also protect us against
active attacks, by making it impossible to spoof the keys provided in the
DNS.

> One interesting issue with radio networks is Man-in-the-middle attacks,
> because nobody can intercept a request and forward it
> faster than you can receive it directly, unless there are
> distances that are too far for the two parties to reach each other
> but still let the MITM contact both.

There's almost certainly an Ethernet hop or a wireless repeater
somewhere between the two ends of the IPSEC tunnel (or the TCP
connections from your mobile node), where a mere wiring change or
firmware patch will insert a black box in the middle.  And there are
also the techniques of listening to most of the packet, and then
garbling its epilogue by jumping a conflicting transmission into the
ether, making the real recipient decide that they didn't get a good
copy.

	John



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com