Re: kernel-level key management subsystem

travis+ml-cryptographysubspacefield.org writes:
>On Mon, May 21, 2007 at 01:44:23PM +1200, Peter Gutmann
wrote:
>> >Ignoring special-purpose hardware, does anyone
have thoughts on what the
>> >requirements for a kernel-level key management
subsystem should be?
>>
>> Yes, but first you'd have to tell me what you're
trying to do.
>
>Protect keys in kernel land rather than userland.
>
>Allows for things like e.g.
>1) marking memory unpageable (avoiding swap hazard)
>2) relocating the data to different physical pages to
prevent
>   burn-in
>3) secure wiping

OK, those are all pretty trivial in terms of having an
identified problem to
solve.

>4) providing a common system for storing and protecting
them
>   rather than doing it in each individual application
>5) allowing for them to be shared securely among
processes (like
>   ssh-agent and gpg-agent)
>6) provide protection against userland snooping
>   programs (gdb anyone?)
>etc.

Right, and that's what I wanted a definition for.  95% of
the what you're
asking for is defining the problem, and that's what I was
after.  For example
how do you want access to the keys controlled?  ACLs?  Who
sets the ACLs?  Who
can manage them?  How are permissions managed?  What's the
UI for this?  Under
what conditions is sharing allowed?  If sharing is allowed,
how do you handle
the fact that different apps (with different levels of
security) could have
access to the same keys?  Do you derive keys from a master
key?  Do you
migrate portions of the app functionality into the kernel to
mitigate the
problems with untrusted apps?  How is key backup handled? 
What about

[Another 5 pages of questions]

Once you've got a clear statement of exactly what you want
to do (which in its
most abstract form is "solve an arbitrarily complex key
management problem"),
implementation is almost trivial in comparison.

Peter.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Tue, Oct 09, 2007 at 06:08:44PM +1300, Peter Gutmann
wrote:
> how do you want access to the keys controlled?  ACLs? 
Who sets the ACLs?  Who
> can manage them?  How are permissions managed?  What's
the UI for this?  Under
> what conditions is sharing allowed?  If sharing is
allowed, how do you handle
> the fact that different apps (with different levels of
security) could have
> access to the same keys?  Do you derive keys from a
master key?  Do you
> migrate portions of the app functionality into the
kernel to mitigate the
> problems with untrusted apps?  How is key backup
handled?  What about
> 
> [Another 5 pages of questions]

Good stuff.

I was hoping perhaps to stimulate a discussion on just these
sorts of issues.

There's a bit of interrelated stuff here; you can start with
requirements,
postulate some mechanisms, think about implications of their
implementation,
which leads to refining requirements.  It's sure to be a
learning experience.

Maybe this isn't the best place to do that, but it seems to
me that this group
would be one of the best for ironing out the details, and
would have a vested
interest in any such management interface not suck.

Ideally I'd like to be able to develop something for, say,
Linux, and possibly
integrate it with your open-source co-processor stuff.

> Once you've got a clear statement of exactly what you
want to do (which in its
> most abstract form is "solve an arbitrarily
complex key management problem"),
> implementation is almost trivial in comparison.

Sure.

Maybe that's a good question: what are the idioms in key
management?

Is there any similar work already that I could read up on?

Where can I read up on current HSM functionality, offerings,
features, etc.?

  "Computers are useless; they can only give
answers."
   -- Pablo Picasso
-- 
<URL:http://www.
subspacefield.org/~travis/> Eff the ineffable!
For a good time on my UBE blacklist, email johnsubspacefield.org.