[E-Lang] Bill Frantz saves the Stock Exchange
Marc Stiegler
marcs@skyhunter.com
Thu, 12 Apr 2001 14:35:36 -0700
In my last email I mentioned in passing I'd been on the phone with zooko.
The bulk of that conversation was about the E comm system. A substantial
part of the conversation wound up discussing a possible man-in-the-middle
attack on the Stock Exchange program I banged out one weekend for markm to
use as an example for FC'00. By the time we got done talking, I thought
zooko might have figured out a way to breach the exchange. I was pretty
glum, because zooko had probably won the 10-grams of e-gold prize I had
posted for just such a breach.
Sorry, zooko. Your attacks only seemed to have a chance because of my
ignorance of the immense subtlety with which Bill Frantz built VatTP. All my
ignorance of comm and security, being a simple E programmer, was still not
enough to endanger the exchange.
Thank you, Bill, for saving my neck :-)
Zooko's attacks were variations on replay attacks. I shall describe 2 of
them here, and how Bill defended me, so everyone can appreciate the beauty
of how E's infrastructure protects the innocent (and naive).
Simple variation 1: A buyer sends a "bid" message to his agent on the
exchange (the agent is an object, not a person :-). The marketplace,
starting with this message, verifies the asset swap and performs the swap in
a single vat game turn. The man in the middle, doing traffic analysis,
records the bid message and replays it, hoping to make 2 swaps occur (so you
exchange 2000 shares, not the 1000 shares you had planned). This will not
work because each message carries with it a new key for the next message;
the replayed message is using a stale key.
Clever variation 2: The buyer sends a "bid" message, but the middleman holds
the message and breaks the connection. Now the buyer (who does not know
whether the message went through or not) starts a new connection (with a new
agent, he does not try to re-establish a connection with the old one). He
gets a fresh view of the marketplace, in which the bid clearly has not gone
through. He submits a "new" bid, which is identical to the old one. The
middleman waits till traffic analysis suggests the rebid has probably gone
through, then plays the old message to the old agent to get a second copy of
the bid initiated.
Sorry, zooko, bill covered that one too. When a vat establishes a new
connection to another vat, all the liverefs through the old connection are
killed dead: only one vat-to-vat connection is allowed at a time. Playing
the old message after a new connection is established will go nowhere.
All of this does not mean that zooko's ideas for CapTP are without merit. It
only means that defense against replay and middleman attacks are not among
those merits.
And it reminds me forcefully of how wonderful it is to be working inside a
seriously thought out secure distributed infrastructure like E's :-) Oooh,
and it's deadlock free, too :-)
--marcs