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

Comments

OS X Keychain is not "application level"

[Anonymous Coward]

On OS X, the keychain data (certificates, keys, etc) is not managed at the application level. There is a system daemon, securityd, that applications talk to if they need passwords or need data signed / decrypted or if they need credentials for a particular service.

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.

Re:Eggs and baskets

[Just Some Guy]

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.

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.

Much like KDE's kwalletmanager

[Straker Skunk]

Same idea in KDE, and I'm sure GNOME has a similar mechanism. Whether these are "OS-level" or "application-level" is a subtler question, but 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.

No

[John.P.Jones]

OpenSSL was just certified FIPS 140-2, that is NOT however level 2 it is version 2 of the standard. It was certified FIPS 140-2 level 1.

Linux Kernel keyring; openCryptoki

[omnirealm]

Current versions of the Linux kernel have a key retention feature. For PKCS#11, there is openCryptoki.

Re:Linux Kernel keyring; openCryptoki

[tlhIngan]

Any idea if that mechanism addresses the DRAM "memory" effect described in this paper: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_ del.html?

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.