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?
participants (4)
-
Adam Shostack -
Alex Strasheim -
frantz@netcom.com -
Perry E. Metzger