Slashdot Log In
Secure Private Key Storage for UNIX?
Posted by
Cliff
on Thu Mar 01, 2007 07:51 PM
from the kernel-level-key-ring dept.
from the kernel-level-key-ring dept.
An anonymous reader asks: "Microsoft Windows, from 2000 forward (except ME) offers secure certificate and private storage at the OS level in what is called a protected store. Offline, it's encrypted by a combination of the user's password and a session key stored on the filesystem. When the OS is running, the private keys stored are available to the logged in user, optionally encrypted with another password. The keys are stored in protected memory, so no applications can access them without going through the Microsoft CAPI calls. This code also is FIPS 140-1 level 1 (the best one can get for software cryptography modules) compliant." Does any other OS provide this kind of feature at the OS-level? If so, who? If not, why?
This functionality (especially certified FIPS 140-1 or FIPS 140-2) would be nice to see in UNIX variants. MacOS's key-chain functionality is similar, but stores at the application level, and is not FIPS compliant. An implementation of the protected store functionality will allow applications like Firefox, Thunderbird and gpg to have one common place to obtain private keys and certificates rather than maintaining their own individual key-stores. An additional application for this would be the ability to use hardware PKCS #11 tokens.
I am wondering why this functionality does not exist at the OS level in most OSes except Windows. A number of applications on many platforms have this functionality, but its at the app level, with their own key-stores, and not a standard at the OS level."
I am wondering why this functionality does not exist at the OS level in most OSes except Windows. A number of applications on many platforms have this functionality, but its at the app level, with their own key-stores, and not a standard at the OS level."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Well duh.. (Score:4, Insightful)
Re: (Score:3, Informative)
He didn't specify Linux, he said UNIX.
Re: (Score:2)
Re: (Score:3, Informative)
HP has 3 (4?) flavors of UNIX:
http://welcome.hp.com/country/us/en/prodserv/serve rs.html [hp.com]
HP-UX, Linux, Tru64
They also have UnixWare, though I'm not sure if that's UNIX or an application suite for UNIX, or something that is "kinda like but not really" UNIX.
VMS is not UNIX, so I won't count that.
Given that these are "for sale", I don't think "dead" is quite the appropriate term.
You can drop out Linux since it's not a IBM creation, reducing their number of Unix OSes by 1, but th
Re: (Score:2)
OS X Keychain is not "application level" (Score:5, Informative)
Much like KDE's kwalletmanager (Score:5, Informative)
Parent
Lack of central planning is the problem here (Score:3, Insightful)
this has more to do with the situation that Linux desktop systems don't necessarily have a centrally-planned infrastructure in the manner of Windows or MacOS X, rather than that they haven't addressed this problem at all.
This lack of a centrally-planned infrastructure is exactly the problem in this case. Some developers, especially government contractors, want assurance of the quality of code, and their idea of assurance is papers stating that a corporation has put money into improving and certifying a given solution to a given government-approved standard.
Keychain is at the application level? (Score:4, Informative)
I'm not sure what they're trying to claim here, but unless their definition of OS means "kernel", the Mac OS X (and classic Mac OS, AFAIK) keychain most certainly is an OS-level service. Keychain items can be shared among all applications, though most applications limit access to these items to a list of trusted applications for obvious security reasons.
I don't know about the question of protected memory or FIPS certification, but the rest of this question just seemed like FUD to me.
chmod 600 (Score:2, Informative)
Just make sure to store the key encrypted with a passphrase
FIPS Levels (Score:3, Insightful)
That's odd, OpenSSL was just certified to level 2 (FIPS 140-2). [linux.com]
No (Score:5, Informative)
Parent
Eggs and baskets (Score:5, Insightful)
An implementation of the protected store functionality will allow applications like Firefox, Thunderbird and gpg to have one common place to obtain private keys and certificates rather than maintaining their own individual key-stores.
Maybe it's just me, but I think that putting all your eggs in one basket is not smart. All it would take would be on critical vulnerability to be discovered and all of a sudden a potential attacker can get to all of your keys. Not good if you ask me.
Re:Eggs and baskets (Score:5, Informative)
I disagree. Right now, we're putting all our eggs in a bunch of half-assed baskets woven from tissue paper and lunchmeat. I'd much rather trust one well-audited, well-engineered solution than the 100 home rolled ones we have to trust now.
KDE does this now with KWallet (although without the spiffy kernel-level protections the author claims that Windows supports). If I'm writing a KDE application, I don't have to worry about getting password storage right - some other folks who know a whole lot more about the problem have already taken care of it for me.
I think this is good in the same way that using libc's strncmp is better than writing your own. Sure, there might be some undiscovered flaw lurking that's just waiting to open our systems to the world, and an environment of heterogeneous strncmp implementations would keep a successful attack from owning everything that links to libc. And yet, I have a lot of faith that the libc version is much better than anything I'm likely to come up with on my own.
Finally, if an error in strncmp were to be discovered, an upgrade of one library file would fix every dynamically linked program on my system. If each of those programs used their own, then each one would have to be audited to make sure they weren't broken in a similar way. In the same way, an upgrade to KWallet helps every program that uses it. Other programs have to hope that new vulnerabilities are specific to KWallet's own code and not a more general problem.
The Unix way is to build a tool that does one thing supremely well, then trust it. I think this is a prime candidate for the same treatment.
By the way, I'm only using KWallet as an example because I'm familiar with it; I'd be even more interested in Theo de Raadt getting a wild hair and writing OpenSecureStore some weekend.
Parent
Aladdin eToken (Score:2)
They are quite good if you don't need frequent encryptions and signatures, well supported by openssh, opensc and openssl, less with gnupg, and firefox but I didn't experiment much.
Just be sure to use the 32K version as the 64K version lacks support.
If not, why? (Score:2, Insightful)
Linux Kernel keyring; openCryptoki (Score:5, Informative)
Re:Linux Kernel keyring; openCryptoki (Score:5, Interesting)
Having developed for embedded systems, I'm amazed at how well DRAM can retain data. I've had it such that RAM disks were preserved after power cycles (~1 second without power, and SDRAM controllers not initialized until many milliseconds after powerup). There was at one point a hack we had to implement in the bootloader to clear a bit of memory so a power cycle really would start clean.
Heck, it's a great way when debugging - the OS could log all messages to the screen, but that greatly slows down operations. So we log into a circular RAM buffer. When the board crashes, we power cycle, then inspect the RAM buffer for the last few messages written.
Out of curiousity, I once experimented to see how long the data was retained - I wrote a data pattern to RAM, looked at it back, then removed power for varying lengths of time. It can take anywhere from a few seconds to a minute before the data gets hopelessly corrupted. But before then, if you knew what you were looking for, you could find it.
Parent
I think we did this first... (Score:3, Insightful)
... but what's magical about the "OS level"? According to Microsoft, Internet Explorer is part of the OS, so anything they say about "OS level" is really irrelevant.
We've been mounting home directories on encrypted filesystems for decades, so that's one way to do this. OS X has this built in and very easy to enable.
Which is pretty much how we do this already; just read the file. If the user had a passphrase, use that to decrypt it.
Well, on Unix, no application can access any other application's memory, period. End of story.
There are ways around this -- you could do tricks with kernel memory, or you could read it off the swapfile. However, I believe there is a way to request that a specific chunk of memory never be swapped out, and while it's in RAM, if your kernel's safe, your app is safe. And it's always possible to run without swap, or encrypt your swap.
On Windows, I believe you can "attach" to a running process with a debugger. On Unix, if you want to debug, you have to start the app in a debugger, because once it's running, the app's memory is its own. Only way you can "attach" then is if the app specifically has a way to do that -- for instance, browser plugins are essentially an app deliberately loading code from somewhere else into itself and running it. But if an app doesn't go out of its way to let you in, you aren't getting in, and if your kernel is owned, so are you, even on Windows.
What does FIPS compliance mean?
And once again, "application level" is a pointless distinction. Yes, there are mechanisms for storing keys at the kernel level, but in my mind, that's less secure because it's much more complex for no good reason.
So have them all use libgpg or something. But what is the advantage?
In Thunderbird, I have a PGP key that I sign my mail with, and I have a password that I use to connect to the server. In Firefox, I have an entirely different set of passwords, and the public keys to some Certificate Authorities. Firefox needs none of the Thunderbird keys/passwords, and vice versa. On the commandline, I have an ssh key, which I use to shell in to other boxes -- which is a key that I don't use in Firefox or Thunderbird.
What's the advantage of putting these all in the same app? And what's the advantage of that app being "OS level"?
Ultimately, the only advantage I see is with something like OpenID. It'd be nice if I could use the same keys I use with ssh to gain access to my OpenID server. Unfortunately, I haven't managed to get my hands on a working server implementation of OpenID, so that's moot.
Re: (Score:3, Informative)
On Windows, I believe you can "attach" to a running process with a debugger. On Unix, if you want to debug, you have to start the app in a debugger, because once it's running, the app's memory is its own. Only way you can "attach" then is if the app specifically has a way to do that -- for instance, browser plugins are essentially an app deliberately loading
code from somewhere else into itself and running it. But if an app doesn't go out of its way to let you in, you aren't getting in, and if your kernel is owned, so are you, even on Windows.
huh?
what about
strace -p pid
gdb program pid
Attaching debugger to running process in Linux (Score:4, Informative)
SanityInAnarchy has apparently not been doing a lot of development in a UNIX environment. While I don't blame him/her for potentially missing out on the ptrace syscall, as it's not mentioned in Stevens' Advanced Programming in the UNIX Environment, I do find it a bit sad that he/she makes such bold statements about the security of a computer system without checking at least the valid command line parameters to one of the tools he is referring to. Luckily an Anonymous Coward already told the world about two of these.
For those not familiar with the ptrace syscall, here is some info about linux ptrace:
Detecting that you're being traced is possible, but it equally possible to circumvent possible detection by tracing at the correct time, deliver spoofed signals, modifying memory in the traced process to avoid being detected. In short: if you cannot trust your system administrator and yourself (at least all processes running as you) you are out of luck as to local security. Network security is one step worse, in that you have to trust even more persons.
Oh, and don't use trustno1 as password!
Parent
Re: (Score:3, Funny)
Re:Protected memory (Score:4, Interesting)
You can play games with hypervisors (can protect memory even from 'ring 0') or treacherous computing chips, or things like USB keystores with biometric authentication. But on vanilla 80386 machines, the best you're going to get is the OS to memlock() a few pages so they can't get swapped out to disk.
Parent
Re: (Score:3, Interesting)
True, a smart card (compared to a normal PC) sucks less, but it still sucks.
Re: (Score:3, Insightful)
People who need such protection all encrypt whole file system and do not bother with only password/key storage. Linux/UNIX does that for all time I know (Crypto Loop patches is probably oldest patch set for Linux). Windows/Vista I heard can this now. MacOS X allows only to encrypt user home directory what is sufficient in most situations - since keys belonging to user are always saved in user's home directory.
That protection was needed by Windows XP and earlier since it didn't supported FS encryption. A