[lug] socket programming/kernel question

[Bear Giles]

Zan Lynx wrote:
> How about a cryptographic cookie in each request?  Doesn't secure NFS do
> something like that?

You get lost in your own navel.  Secure NFS requires secure RPC, 
and secure RPC uses a "keyserv" daemon to get the (public?) keys 
as necessary.

This server is similar... only instead of providing access to 
keys, it provides cryptographic services to the caller - there's 
no need to expose the keys.  In many ways it's intended to act 
like a virtual smart card, only without the overhead of the full 
cryptoki API.

That's the first problem - with a real smart card there's a 
physical reader that can be locked.  This virtual reader may have 
hundreds of concurrent instances.

What makes it even more complex is that a lot of the clients can 
use ephemeral keys.  They're generated on demand, and should 
disappear without a trace afterwards.

But that pretty much eliminates crypto solutions.  If I had the 
private keys to use to sign this traffic, I wouldn't need to use a 
crypto engine with hidden private keys.

(P.S., there's one other solution.  Each client has its own 
permanent cert/key, it generates its own ephmerical keys and 
self-certifies them, then drops the permanent key.  It then uses 
that key to sign traffic to the server... but if it's generating 
its own ephemeral keys why do I need the server?  (The answer is 
that the server may have access to real smart cards, etc.))