Re: Remailer passphrases

At  2:51 PM 3/12/96 -0500, Perry E. Metzger wrote:
>Bill Frantz writes:
>> One of the reasons classical (government) crypto users change keys
>> frequently is to minimize the amount of data compromised by a broken key. 
>> We keep hearing about NSA decrypting 20 year old cyphertext and showing
>> more of the workings of the atomic spy rings operating in the 40s and 50s. 
>> If an opponent can rubber hose the key, her job is easy.  If she has to
>> perform cryptoanalysis, it is much harder.  Remailers should regularly
>> change their keys to avoid compromising previously recorded traffic.  (They
>> can have a long lived key for signing their traffic keys.)
>
>Signed Diffie-Hellman key exchanges have the property known as
>"Perfect Forward Secrecy". Even if the opponent gets your public keys
>it still will not decrypt any traffic for him at all -- it just lets
>him pretend to be you. Thats one reason why protocols like Photuris
>and Oakley use the technique.

Unless I am badly mistaken, these exchanges need interaction, which makes
them unsuitable for simple remailers.

Regards - Bill


------------------------------------------------------------------------
Bill Frantz       | The CDA means  | Periwinkle  --  Computer Consulting
(408)356-8506     | lost jobs and  | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA

Bill Frantz writes:
> >Signed Diffie-Hellman key exchanges have the property known as
> >"Perfect Forward Secrecy". Even if the opponent gets your public keys
> >it still will not decrypt any traffic for him at all -- it just lets
> >him pretend to be you. Thats one reason why protocols like Photuris
> >and Oakley use the technique.
> 
> Unless I am badly mistaken, these exchanges need interaction, which makes
> them unsuitable for simple remailers.

Well, actually, you can play similar tricks with El Gamal...

Perry

If we ignore the obvious problem (ie., no one is going to put much effort
or expense into running a free remailer), wouldn't splitting the remailer
across two machines help fix the security problem? 

Suppose one unix box accepts the mail and puts it a queue directory.  Then
a second box periodically grabs files from the first box's queue with ssh
(the second box initiates the connection), processes them, and then passes
them out to the smtp server on the first box.  The second box doesn't
accept incoming connections on any port except for the ssh port so there
are no sendmails or httpds to hack.

The remailer files could be running on a cfs drive (with nfs/cfs only
accepting connects from localhost), and you could disable getty so that it
would be hard to physically grab the machine and read the contents of the
disk.  If you had enough ram you wouldn't need a swap file, so there'd be
nothing there for someone who grabbed the machine.  If you set the machine
up while it's plugged into a small lan that's not connected to the net no
one could come in and hide something before you had secured everything. 

You'd also have to try to make as sure as is humanly possible that there
is no way an attacker can construct a trojan remailer packet that would do
something unpleasant.

Finally, don't tell anyone what you're doing or how you're doing it, and
don't post about it to cypherpunks.  It may be unwise to depend on
obscurity for security, but as an extra layer it can't hurt and it might
cause a physcial attacker to come unprepared to hack the machine without 
powering it down and rebooting.

I know an attacker could interrupt service, and I'd guess that a skillful
attacker could probably find a way to grab the cfs and remailer
passphrases if he could grab the machine and the control the site
physically (to work on it while it's running) for awhile, but how would an
attacker come in over the net and hack the remailer box?  

What have I overlooked?

Alex Strasheim wrote:

| If we ignore the obvious problem (ie., no one is going to put much effort
| or expense into running a free remailer), wouldn't splitting the remailer
| across two machines help fix the security problem? 

	This is a long standing debate in the security community.
Some folks like multiple box security.  Others point out that using
two boxes means both need to be well secured, and you have twice as
many places to make mistakes.

| Suppose one unix box accepts the mail and puts it a queue directory.  Then
| a second box periodically grabs files from the first box's queue with ssh
| (the second box initiates the connection), processes them, and then passes
| them out to the smtp server on the first box.  The second box doesn't
| accept incoming connections on any port except for the ssh port so there
| are no sendmails or httpds to hack.

	Lets say the boxes are called workstation and blackbox.  If I
break into workstation, I can provide bogus files for blackbox.  Since
blackbox extends some trust to workstation, it might not be expecting
to see a message with a return address of "`|telnet evil.fbi.gov`".

	I'd argue that setting up a simple mailer which uses
workstation as a relay host gives you as much security, and lessens
your dependance on workstation, which we expect will be comprimised.
(Of course we expect ws to be comprimised.  Why else are we setting up
bb as a seperate machine?)

| The remailer files could be running on a cfs drive (with nfs/cfs only
| accepting connects from localhost), and you could disable getty so that it
| would be hard to physically grab the machine and read the contents of the
| disk.  If you had enough ram you wouldn't need a swap file, so there'd be
| nothing there for someone who grabbed the machine.  If you set the machine
| up while it's plugged into a small lan that's not connected to the net no
| one could come in and hide something before you had secured everything. 

	Turning of getty and removing the swap file strike me as a bit
extreme.  A panic login system, otoh, that accepts a bad password and
wipes the disk, might not be a bad idea.  (Of course, if this becomes
popular, the bad guys will just rip out your disk and read it on
another machine.)

| I know an attacker could interrupt service, and I'd guess that a skillful
| attacker could probably find a way to grab the cfs and remailer
| passphrases if he could grab the machine and the control the site
| physically (to work on it while it's running) for awhile, but how would an
| attacker come in over the net and hack the remailer box?  

	Be awful tough if it only listens to ssh & smtp.  Are you sure
your kernel doesn't do anything bogus with ICMP?  Data overflows in
ssh or smap?  DNS, syslogd, tty overloads?

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

(warning:  I don't know much about security, so if you don't either, 
don't take what I have to say too seriously...)

> 	This is a long standing debate in the security community.
> Some folks like multiple box security.  Others point out that using
> two boxes means both need to be well secured, and you have twice as
> many places to make mistakes.

Ok, I see your point.  If someone compromises workstation, they can read
all the mixmaster packets by looking at what comes in and out of blackbox. 
But they still can't grab the passphrase and key, so old and future
traffic is safer, and if there's a large reordering pool they'll have
trouble matching a given incoming packet with a given outgoing packet. 

> 	Lets say the boxes are called workstation and blackbox.  If I
> break into workstation, I can provide bogus files for blackbox.  Since
> blackbox extends some trust to workstation, it might not be expecting
> to see a message with a return address of "`|telnet evil.fbi.gov`".

It seems to me that if you're just running a remailer that only talks to
one other machine, it ought to be possible to eliminate this kind of a
problem.  Blackbox grabs a file from a queue on workstation, runs it
through mixmaster, and deposits the output in an outgoing queue on
workstation.  If the trojan file is something strange, it will just drop
through mixmaster.  Maybe it would choke workstation on the way out, but
blackbox -- and the passphrase -- would be safe.

> 	I'd argue that setting up a simple mailer which uses
> workstation as a relay host gives you as much security, and lessens
> your dependance on workstation, which we expect will be comprimised.

If we leave sendmail on, we're hosed -- wouldn't bb moving packets on and
off workstation with ssh's rcp be a lot safer? 

> (Of course we expect ws to be comprimised.  Why else are we setting up
> bb as a seperate machine?)

Agreed.

> 	Turning of getty and removing the swap file strike me as a bit
> extreme.  A panic login system, otoh, that accepts a bad password and
> wipes the disk, might not be a bad idea.  (Of course, if this becomes
> popular, the bad guys will just rip out your disk and read it on
> another machine.)

I admit freely that this is all extreme and impractical...  I was just
trying to think through the problem.

I was shooting for a system that would be worthless to an attacker if it
was turned off, and which couldn't be hacked easily from the console
without turning it off.

A crypto file system directory will be worthless if the machine goes down,
and if there's no swapfile, there's not going to be anything nasty left
behind there.  The bad guys *can't* rip out your hard drive and read it,
because all the good stuff is on the cfs drive -- it's just a big blob of
idea'd data, and neither the remailer' or cfs's passphrase was ever
written to disk.  

When bb boots, it waits for the sysadmin to ssh in and mount the cfs drive
manually, then start the remailer manually.

If the attacker didn't know what you've got in place, he'd probably just
steal the machine assuming he could get something out of it when he's got
it back on his workbench.  If he did know the details of the system, he'd
be faced with trying to extract the cfs and remailer passwords from the
machine's ram without turning it off and without being able to login from
the console -- ideally you wouldn't even have a keyboard plugged in.  (I
have no idea how hard it would be to steal information from a running
machine's ram -- or if it's even possible).

> 	Be awful tough if it only listens to ssh & smtp.  Are you sure
> your kernel doesn't do anything bogus with ICMP?  Data overflows in
> ssh or smap?  DNS, syslogd, tty overloads?

Actually, it only listens to ssh;  a bug there is fatal.  Same goes for
the kernel.  We don't need dns -- to bb, the only other machine in the
universe is workstation, and it knows the IP address.

If the core system can't run without incident, you're in trouble.  But 
couldn't you do a pretty good job of shielding it from surprises by 
turning almost everything off and not letting it talk to the outside 
world, except in very narrow ways?