[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
