Subject: Re: BPG Security Server
To: Steven M. Bellovin <smb@cs.columbia.edu>
From: Curt Sampson <cjs@cynic.net>
List: tech-security
Date: 07/26/2005 11:32:47
On Mon, 25 Jul 2005, Steven M. Bellovin wrote:

> First -- how does the PGP server interact with the user?  Let it speak
> only stdin/stdout in a separate xterm, screen window, or alternate
> console?  It's possible, though the human factors don't impress me.

Yes. It's actually not so bad, I think, if you're using X and are using
this with several apps.

> For that matter, how does the user know there isn't some other
> application reading stdin in that xterm/screen window/console?

You have the same issue no matter whether you use a server or not;
something could just as easily take over the client window. Presumably
one always uses xterms "secure keyboard" option in an xterm whenever
doing anything like this. A special-purpose console window for the
server could do a better job at this, by turning on the secure window
feature automatically, say, when requesting passwords and suchlike.

Better would be to have the console running on another machine that is
kept more secure, say, your laptop. Or perhaps one could come up with
a stand-alone device to be the server and console that attaches via
network or USB.

My first question about this, before I get into too many of the details,
is, "is this security model an improvement over what else is available,
e.g., typing my passphrase into all my various applications?"

> Second -- how does the server authenticate the application that's
> asking for a key?  That is, how does it know that it's bpg and not some
> Trojan horse that's been lurking in the background?

First, the application does not get a key, it gets only encryption
and/or signing services. If you trust the console, you are guaranteed
that when the application sends signed or encrypted, it's signed or
encrypted with the keys you specified in the console.

As for authentication of the client, I've been wondering about that. It
would depend on the communications protocol as well, of course.

     1. You could use the time of the request. If you ask a program to make
     a request, and you see that right away in the console, and no other
     requests around that time, that gives you some indication that it's
     the correct one.

     2. You could provide a nonce to the client that it would then have
     to provide to the server (presumably via an encrypted connection).

That starts to lead into the question of how the client authenticates
the server. But that could be done with a nonce, too, couldn't it? This
is almost starting to look like Bluetooth.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.NetBSD.org
      Make up enjoying your city life...produced by BIC CAMERA