kernel-level key management subsystem

[Peter Gutmann]

travis+ml-cryptography at subspacefield.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 majordomo at metzdowd.com