kernel-level key management subsystem

Ignoring special-purpose hardware, does anyone have thoughts
on what
the requirements for a kernel-level key management subsystem
should be?

-- 
Kill dash nine, and its no more CPU time, kill dash nine,
and that
process is mine. -><- <URL:http://www.
subspacefield.org/~travis/>
For a good time on my UBE blacklist, email johnsubspacefield.org.

"Travis H." <travis+ml-cryptographysubspacefield.org> writes:

>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.

Peter.

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

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
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.

-- 
<URL:http://www.
subspacefield.org/~travis/> Eff the ineffable!
For a good time on my UBE blacklist, email johnsubspacefield.org.