By way of preamble for those (on DCSB, of course :-)) who don't know,
IPSec: Internet Engineering Task Force's Internet Protocol Security
standard. It means strong, completely transparent, "opportunistic"
encryption at the level of internet packets themselves.
FreeS/WAN: A project funded by John Gilmore to do IPSec on Linux. It
works. It's free. And, now, apparently, it's going to the bank,
because,
The "Ivan Moore" Gilmore's responding to below is:
> Ivan E. Moore II [EMAIL PROTECTED]
<Phone numbers snipped in pity...>
> Network Security Analyst Capital Markets
> Internet and Remote Access Group First Union
...a man who says, later in this same thread,
At 4:31 PM -0400 9/10/99, Ivan E. Moore II wrote:
> a little over 5 hours
> for download, compile, config to get it to talk to the Shiva box. (that
> includes config'ng the Shiva box as well)
Financial cryptography is the only cryptography that matters.
Cheers,
RAH
--- begin forwarded text
To: "Ivan E. Moore II" <[EMAIL PROTECTED]>
cc: Linux IPsec <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: linux-ipsec: Defense in depth
Date: Fri, 10 Sep 1999 11:28:32 -0700
From: John Gilmore <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
It makes me both proud and scared that you're using FreeS/WAN to secure
the infrastructure for part of the financial system. Proud because we
tried to design the best security we know how to, scared because we
may have screwed it up somehow. (We have powerful adversaries working
hard to make sure they can read or alter communications that we are
trying to secure -- and e.g. they designed IKE!) Thanks for the
vote of confidence. We're doing our best to engineer solid foundations
for the infrastructure of trust that our society depends on.
I understand your desire for defense-in-depth to limit the damage from
catastrophic failure of a single cipher or protocol. Since FreeS/WAN
is open source software, you can change it yourself to meet your
requirements if they are unique. My guess is that other parts of the
social infrastructure will also need similar tools. If the FreeS/WAN
maintainers understood the requirements well, and could support them
without undue cost (in complexity of administration, for example),
we'd all be better off.
Layering several encryption schemes tends to provide better security
than any individual scheme, if you don't alter each individual scheme
IN ANY WAY, and if you take care that the keys used are truly
independent. (Altering a cipher as part of layering it is perilous;
most such ciphers become very fragile. Eli Biham has published a few
good papers on this. And if both IPSEC and SSH get key material from
a comprimise-able /dev/random, you have not solved your problem.)
A good way to layer schemes involves applying encryption at several
layers of the networking model, e.g. use link-level encryption (ATM
encryptors) plus network-level encryption (IPSEC) plus
application-level encryption (SSH). If these layers don't know
anything about each other, and run on separate hardwre, so much the
better. (Of course you have to deal with computer security on the
machines involved: if I can get a root shell on the machine that runs
the application, it doesn't matter how many layers of encryption protect
its communications.)
Your desire for ESP inside AH makes me wonder what you are trying to
defend against. Must the data be kept private? Or must it simply be
transmitted unchanged?
AH only prevents alterations, it has no effect on privacy. If you
need defense-in-depth of privacy, it would be better to layer ESP
inside ESP (inside ESP...). The RFC's don't require this combination
(mostly due to the complexity of testing large numbers of required
combinations), but it is designed to work, and I think FreeS/WAN could
agree to support it at some point. Each level of ESP could use a
different cipher and hash function. You'd still have IKE and
randomness as single points of failure, but would be protected against
catastrophic failure of a cipher or a Message Authentication Code.
This is the first good reason I've heard for including a cipher other
than 3DES in our release; congratulations. If we included a
relatively weak cipher, layering the weak cipher on a strong cipher is
unlikely to damage the security of the strong cipher. But making a
weak cipher available does encourage innocents to use the weak cipher
alone ("for high speed"), and being able to break the weak cipher
would reveal key bits that would make an imperfect randomness source
easier for a serious attacker to compromise. So we'll probably still
only provide strong ciphers, such as 3DES and the eventual AES, and
support layering them for the truly paranoid such as yourself. (In
your application, to protect against the IKE and randomness
vulnerabilities -- which I consider much more problematic than an
attack on the 3DES cipher itself -- you'd still want independent
link-layer and application-layer encryption too.)
My guess is that it's easiest to steal money by altering your
datastream, but the thief is likely to get caught by accounting
controls at the application level. A better way for an eavesdropper
to steal long-term is to watch the transaction stream and place market
bets based on what they see. Detecting that this sort of theft is
happening at all is tough, involves much more complex analysis of the
market's dynamics, and doesn't necessarily point out who's
manipulating the market.
E.g. I've noticd that SUNW stock tends to rise a few days *before*
something good is announced, and then falls quickly afterward.
*Somebody* is buying the stock cheaply based on anticipating the
announcement, and then selling it on the day of the announcement when
people are willing to pay more for it. They make money from people
who didn't know the announcement was coming -- but all the
transactions completed properly and all the accounting controls were
satisfied. (When done by insiders, this is called "insider trading"
-- but it can also be "eavesdropper trading".) This could be done on
a scale of seconds instead of days, by someone who could watch
large-scale orders for stocks or currencies being communicated inside
the financial system. If the transactions relate to mergers and
acquisitions, advance knowledge provides a very strong financial edge
to the eavesdropper, since the stock prices of the companies involved
can change suddenly by large percentages in an anticipatable way.
This would indicate to me (an outsider as far as financial system
design is concerned) that protecting the privacy of the transaction
stream is just as important as protecting its integrity.
So, tell us more about what you're trying to defend against, and we'll
see what we can do...
John
--- end forwarded text
-----------------
Robert A. Hettinga <mailto: [EMAIL PROTECTED]>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
