Slashdot Mirror
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."
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."
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.
How we know is more important than what we know.
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.
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
chmod 600 crypt.key
:)
Just make sure to store the key encrypted with a passphrase
That's odd, OpenSSL was just certified to level 2 (FIPS 140-2).
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.
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.
iSKUNK!
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.
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.
the NPG electrode was replaced with carbon blac
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.
Current versions of the Linux kernel have a key retention feature. For PKCS#11, there is openCryptoki.
An unjust law is no law at all. - St. Augustine
The thing is, this should be possible in theory. The operating system is the final arbiter of all ring 0 operations, and enforcing protected memory should be one of the basic things it does.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Yes, when there is no actual Microsoft vulnerability available, the crafty Slashdotter can just imagine that one exists, and still get that refershing feeling of superiority!
From "Vista encryption 'no threat' to computer forensics":
Liberty in your lifetime
Just wondering...
--Phillip
Can you say BIRTH TAX
It sounds like Linux needs a good dose of DRM to keep those keys secure.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Er, Lots of stuff lives in ring0, and any vulnerability in ANY of it removes your "protected memory".
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.
Yes, when there is no actual Microsoft vulnerability
Say that out loud a few times.
I want to delete my account but Slashdot doesn't allow it.
...in that form because it's rather domain-specific to Windows. But there are hardware devices out there and drivers that provide interfaces to said harware to provide similar bits.
Most security doctrines operate with the conviction that physical access to the box, along with enough time and resources, negates all possible security measures.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
That'll protect against everything, yep... except other drivers... or DMA devices (I remember a while back someone created a USB device that when it was plugged into the computer could arbitrarily access all data in RAM because of problems with the USB stack), or having the OS ran in a VM, or simply using a key logger to capture the password. I've only seen the Windows password stuff come up a couple times (when writing a VBA application of all things!) and it didn't come up in the 'secure desktop' or anything so it most likely would have been vulnerable to any key logger.
A smart card is the best place to keep your private keys. The key is generated on the card, and never leaves. It is not even possible to get private keys off a smart card, except (perhaps) with an electron microscope.
Any current operating system (yes, linux too) has too many built-in security holes (inadvertent or otherwise), which makes secure storage of anything, including private keys, a joke. At some point, the key must appear in the clear to be useful; for that time, the key is vulnerable to sniffing.
Just as some of the keys for HD DVDs have been found, given a determined adversary, your private key will be found.
We can talk about "less vulnerable" private key storage, but I don't think that's what you had in mind.
It's Linux, damnit! Pay no attention to renaming attempts by self-aggrandizing blowhards.
Well... I did say "in theory" :-) Allowing unrestricted access for any code labeled "driver" is just a blatantly retarded idea.
I saw a couple people bring up the VM point... presumably if you're doing advanced things like running in a VM, you are aware that the hosted OS is vulnerable to any malicious programs in the host. Since the point of this system is to protect a user's data from malicious apps rather than from themselves (a la AACS), I wouldn't call that as big of a deal.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
... 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.
Don't thank God, thank a doctor!
i am in ur memoriez, hacking all ur encryption.
After all, I am strangely colored.
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.
All hope abandon ye who enter here.
For Lunix :
http://swtch.com/plan9port/man/man1/secstored.htm
http://swtch.com/plan9port/man/man4/factotum.html
in which you can store *any* data, factotum will get the individual keys out for you
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Oh no! Somebody asked something of Linux that it doesn't provide! Better silence him, quick!
I can't find the button that silences the person asking the original question. Is it because I'm using this damn Lunix thing? Another bloody feature it doesn't provide.
I'm just curious - did you come here and post because you work in the field of security and were interested in the question? Or did you come here just to disrupt the discussion with your two "Lunix zealots - LOL!" oneliners? If it's the latter, as it so clearly is, doesn't that make you much worse than the people you're so ineptly trying to mock?
If you're planning to argue the former, please include in your reply a short analysis of the problems with any secure key storage scheme which relies on the OS kernel being able to protect its memory against all attackers. Thanks in advance.
Plan 9 has such a central key repository. It's called Factotum, and the best description is the USENIX paper. It has been ported to other UNIX-likes by the plan9port project.
Darren Bane
Maybe it's not in Unix because there are better alternatives for "real" systems?
For example the IBM 4764 Cryptographic Coprocessor? They're expensive, but more secure than anything a basic machine / operating system could provide. But if you're developing a system that actually has a need for secure keys then surely a price worth paying?
In my view, anything like this built into the operating system is a "poor mans" secure store. Something a home use might like, but certainly not something you'd want to use in a mission critical production system.
I'm pretty sure I "came here" for the same reason most people do, to read news. The occasional poking fun at the zealots is merely a small amusement on the side, and helps one stay sane reading this site.
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!
Geek rants since like... 2000 or something.
Because the author is saying that it uses password & some session key to encrypt. That means, it must be internally generating encryption key from password & encrypt. As for FIPS, password based key derivation functions are not allowed in FIPS mode [PBKDF. I think it is PKCS#5]. One key storage solution is using FIPS compliant hardware to store the keys [using pkcs#11].
According to the breakms papers from Peter Gutmann, the cryptoapi has to store the private keys in the clear, in memory, and this is true from windows 3.1 to XP. No idea about vista.
Wait - *you* the user needs to supply a password to access it, so it looks secure, but the actual key, in memory, is kept in the clear, unencrypted. Don't think just because the system asks for a password that your data is actually secured.
You're right, there needs to be a "-1 Wrong" mod for just this kind of stupidity.
I apologize.
Don't thank God, thank a doctor!
Do people really not keep up with these kinds of shit? Go read Peter Gutmann's breakms paper, all 3 of them.