Secure Private Key Storage for UNIX?

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

Well duh..

[QuantumG]

on Windows it is centralized and conforms to government requirements because, get this, Windows development is centralized, and Microsoft sell Windows to governments. Amazing huh? Now, of course, if you think this is important, and can code, you might feel like going and writing a daemon for handing out certificates. Hardening it against attack, etc. Then go write the support into all these various programs that use certificates. But unless you're willing to do that, we'll just have to wait until Red Hat, Novell, or whoever go for some government contracts that require this level of certification.

FIPS Levels

[Jherek Carnelian]

This code also is FIPS 140-1 level 1 (the best one can get for software cryptography modules) compliant."

That's odd, OpenSSL was just certified to level 2 (FIPS 140-2). [linux.com]

Eggs and baskets

[El Cubano]

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.

If not, why?

[HomelessInLaJolla]

Poor supplicant. You will never reach enlightenment if you still place your trust in secure keys and encryption algorithms. Have not the radar gun vs. radar detectors taught you anything? Has not copy protection taught you anything? Has not DVD, Blu-Ray, or iTunes taught you anything? Has not closed hardware taught you anything? These things are intricacies and crusades of people who are paid to assert that they have completed an impossible task. You ask for feats of engineering when reverse engineering is just as important.

I will happily compile secure libraries, encryption algorithms, and maintain a basic level of privacy measures. I will never ever ever be deluded to think that "protected memory" is indeed protected, that "FIPS 140-1 level 1" is "the best one can get", or that "compliant" means anything other than sophisticated sounding advertising.

This functionality (especially certified FIPS 140-1 or FIPS 140-2) would be nice to see in UNIX variants

I'm sure that somewhere someone has made a program which you can pipe data to and from or which you can use as a wrapper around your network transactions (a la tcpwrapper).

An additional application for this would be the ability to use hardware PKCS #11 tokens

At one time railroad lines had two different track spacings and some roundhouses sported heavy machinery which could quickly change the wheelbases on locomotives and the train cars. Be careful of integration. There is profit motive in change (for the sake of change) and integration makes change very slow and painful.

Lack of central planning is the problem here

[tepples]

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.

I think we did this first...

[SanityInAnarchy]

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

Offline, it's encrypted by a combination of the user's password and a session key stored on the filesystem.

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.

When the OS is running, the private keys stored are available to the logged in user, optionally encrypted with another password.

Which is pretty much how we do this already; just read the file. If the user had a passphrase, use that to decrypt it.

The keys are stored in protected memory, so no applications can access them without going through the Microsoft CAPI calls.

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.

MacOS's key-chain functionality is similar, but stores at the application level, and is not FIPS compliant.

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.

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.

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:Well duh..

[Anonymous Coward]

Um, dude... Your post was 100% "immature asshole."

You may be correct in your facts, but that's immaterial when you stoop to personal attacks and condescending attitude. A mature response would include correcting facts with cited sources.

Re:Loopback filesystems?

[ThePhilips]

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. And even then people were selling special solutions with transparent hard drive encryption: BIOS asks for password and gives it to the hard drive and Windows goes on booting as usual.