Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Secure Private Key Storage for UNIX?

Cliff posted more than 7 years ago | from the kernel-level-key-ring dept.

Encryption 95

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

Sorry! There are no comments related to the filter you selected.

Well duh.. (3, Insightful)

QuantumG (50515) | more than 7 years ago | (#18201240)

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.

Re:Well duh.. (2, Informative)

RollingThunder (88952) | more than 7 years ago | (#18201386)

I'm pretty sure that Sun, IBM, and HP sell their UNIX systems to the government, and centrally develop those too.

He didn't specify Linux, he said UNIX.

Re:Well duh.. (1)

QuantumG (50515) | more than 7 years ago | (#18201494)

IBM and HP don't have UNIX systems anymore.. and for all I know Solaris has something similar to this.. in any case, gpg isn't going to be top on the list of applications used in a government contract.

Re:Well duh.. (1)

endofbroadcast (959133) | more than 7 years ago | (#18201784)

They what? They don't have UNIX systems anymore? When did this happen? HP-UX isn't just 4 letters with a dash in the middle. It's a currently developed/supported OS and is widely used in government systems.

Re:Well duh.. (1)

QuantumG (50515) | more than 7 years ago | (#18201826)

HP-UX is dead.. as is AIX.. try to keep up.

Re:Well duh.. (0, Flamebait)

endofbroadcast (959133) | more than 7 years ago | (#18202218)

Oops. I confused your stupidity for ignorance. Howabout you keep up with the industry, bucko. Your personal opinion means nothing when going up against cold hard facts, you pompous, overbearing windbag. HP-UX is heavily used, and if you just don't want to accept that fact you can curl up with your security blanket, scream "Mama!" and wait for the anal thermometer, because you are a friggin' child. So chill with the semi-coherant B.S. and actualy contribute to the discussion without being a total elitist nerd spitting out nonsense.

Get with the program, buddy, and grow up.

I AM in the know. I DO work for the government, and I KNOW what I'm talking about. Your snotnosed attitude merely shows that you're ignorant of the reality of the situation. Congratulations on proving just how stupid you really are. Bravo, buddy.

Re:Well duh.. (1, Funny)

Anonymous Coward | more than 7 years ago | (#18202344)

Jesus christ chill dude. Go smoke a jay.

Re:Well duh.. (0, Flamebait)

QuantumG (50515) | more than 7 years ago | (#18202346)

I DO work for the government
I can tell by your maturity.

Re:Well duh.. (0, Flamebait)

Anonymous Coward | more than 7 years ago | (#18202706)

Funny... I could tell from his lack thereof.

Re:Well duh.. (0, Flamebait)

endofbroadcast (959133) | more than 7 years ago | (#18202772)

What is that supposed to mean? Just because I called you out on your ignorance of the subject matter doesn't make me immature. It just makes me correct. And now that you don't have a valid argument you have to sink to snide, backhanded comments. Have you ever had to defend a position using facts and not just a snotty attitude?

Re:Well duh.. (0)

Anonymous Coward | more than 7 years ago | (#18205130)

Next time keep your rage to yourself and just post a "you're wrong" with many relevant links. You would do well to get some facts yourself; a "I DO work in government" claim is not a very solid proof of anything.

Re:Well duh.. (2, Insightful)

Anonymous Coward | more than 7 years ago | (#18205160)

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

Hack'n'Slash (3463) | more than 7 years ago | (#18207308)

No, ranting and name calling reflect very poorly on a person's level of maturity.

Re:Well duh.. (1)

hb253 (764272) | more than 7 years ago | (#18205986)

I bump into this kind of ignorance a lot, especially from people who've only ever worked with Microsoft products. When I tell them about "Product X" they'll say something like "I didn't think anybody used that anymore" or "what idiot still uses that outdated system", etc, etc. It's maddening but what to do about it? You can't legislate awareness.

Re:Well duh.. (1)

Richard_at_work (517087) | more than 7 years ago | (#18205392)

AIX is dead? Huh? We just bought three 550 systems a month or so ago and they all came with AIX 5, absolutely no problems ordering them and having it preinstalled.

AIX is far from dead, whatever you may want to believe.

Re:Well duh.. (1)

finkployd (12902) | more than 7 years ago | (#18203076)

IBM and HP don't have UNIX systems anymore.

I have a lot of clients on AIX who will be shocked about that.

And before any of you start in on how AIX sucks, it has a logical volume manager that kicks the crap out of the toy that Linux has.

Finkployd

Re:Well duh.. (1)

nbvb (32836) | more than 7 years ago | (#18203766)

Linux: "This is the year of Linux on the Desktop" for almost 15 years running .....

Seriously, AIX and HP-UX both have kick-ass volume management. Check out Dynamic Root Disk from HP... whoa, cool! And it only works if you have a real LVM ...

Re:Well duh.. (2, Interesting)

linkages (131028) | more than 7 years ago | (#18206242)

If only AIX's memory management was as good as its logical volume manager. mmap on AIX is just broken when it comes to performance.
If you have more that say a dozen processes mmaping a file and one of those procs makes a change all the others _MUST_ be interrupted to have their in proc. memory cleaned up. This becomes an even larger problem when you have hundreds of procs mmaping the same file.

Re:Well duh.. (2, Informative)

jimstapleton (999106) | more than 7 years ago | (#18205848)

So, is this just a hallucination?

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 that's still a positive number.

We use all of the above (except UnixWare) and many more where I work, in various places (LARGE organization).

As for IBM, AIX and Linux. I5 might be a Unix OS also, but I'm not familiar with it.
http://www-03.ibm.com/systems/i/os/ [ibm.com]

Also for sale. And AIX is also still used (they have AIX server in various places in the organization where I work also)

Re:Well duh.. (1)

jack_csk (644290) | more than 7 years ago | (#18206386)

By UnixWare, do you mean this product from our friend in Utah [sco.com] ? For some, UnixWare is considered the directly-inherited child of AT&T's Unix. However, it's a POS comparing to AIX and Linux

Re:Well duh.. (2, Interesting)

tritab (249395) | more than 7 years ago | (#18202138)

Wow, this is the closest I've seen to anyone on Slashdot admitting that Microsoft did something better than any Unix / Linux system in a long time!

But seriously, I've wondered about the same question as the OP and have never found anything good. The closest was setting file system permissions on the key file as someone else mentioned.

Is it not possible?

Re:Well duh.. (1)

QuantumG (50515) | more than 7 years ago | (#18202206)

What are you talking about exactly?

The centralized aspect of Microsoft's solution is the only thing that is seriously different on Linux.. as it is hard to get distributed developers not to duplicate each other's work.

The keys are encrypted in much the same way.

Re:Well duh.. (1)

mysidia (191772) | more than 7 years ago | (#18202538)

It's not really more secure.. if anything it's less secure, it's just more convenient sometimes.

MS needs to use "protected memory" arises only because in windows, you don't necessarily need to be root to mess with other process' memory areas. If a skilled hacker needed to access that memory store badly enough, they could very likely write a kernel driver or otherwise patch the OS to open the little hole they need.

Since the encryption of your certificate is bound to your login password, what do you think happens when an administrator needs to reset your password?

Perhaps to mitigate that someone else figured out your login password, compromised your account and changed the password on you.

Now _you_ have permanently lost access to all your encrypted files, AND, the hacker possibly already has copies.

That's why PGP is nice. You can have multiple private keys, and you can set different passphrases for access to them, independent of your login password.

For casual surfing, you don't need access to your encrypted file stores, it makes sense to require additional credentials before you want to go open a confidential document.

Re:Well duh.. (1)

dhasenan (758719) | more than 7 years ago | (#18203724)

What can the kernel do for you that an application cannot?

Seriously, this is a somewhat complicated operation, and there's little that the kernel can do to keep your data private that an application would be unable to do. Getting access to another process's memory is not a trivial task; it probably requires some trickery with the MMU, and the kernel's in the way. So you could ask for a system call to prevent this from happening, but is there anything else the kernel can do for itself that it can't do for applications?

Is windows key storage FIPS compliant?? (1)

durgaprasad_j (888320) | more than 7 years ago | (#18206280)

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

Windows is certified by the government... (0)

Anonymous Coward | more than 7 years ago | (#18208304)

...because they have ***EXCELLENT*** lobbyists that lobby to get whatever-microsoft-already-did to be the required feature in the Certifications.


I currently work in government sales for software - and no matter how much you love Linux, IF YOU'RE SELLING TO THE FEDS PARTNER WITH MICROSOFT( OR ORACLE). Their lobbyists really are that good.


Once there's legislation requiring your software's features - even if they're stupid ones and worse in all ways than similar features of competitors - you will win the sale. This is *especially* true if your competitor starts arguing that their software is better based on technical merits, and the government buyers start insisting that they replace their strong technology with weaker stuff to comply with the law

OS X Keychain is not "application level" (5, Informative)

Anonymous Coward | more than 7 years ago | (#18201318)

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.

Much like KDE's kwalletmanager (4, Informative)

Straker Skunk (16970) | more than 7 years ago | (#18201458)

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.

Lack of central planning is the problem here (2, Insightful)

tepples (727027) | more than 7 years ago | (#18203610)

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? (3, Informative)

dgatwood (11270) | more than 7 years ago | (#18201384)

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.

uh, what? (0)

Anonymous Coward | more than 7 years ago | (#18201388)

I'm sorry, why is this article posted? For the sole purpose of bashing unix? Someone get the firehose.

Re:uh, what? (0, Troll)

Goaway (82658) | more than 7 years ago | (#18201416)

Oh no! Somebody asked something of Linux that it doesn't provide! Better silence him, quick!

Re:uh, what? (1)

Slashcrap (869349) | more than 7 years ago | (#18205334)

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.

Re:uh, what? (1)

Goaway (82658) | more than 7 years ago | (#18205712)

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.

chmod 600 (2, Informative)

Anonymous Coward | more than 7 years ago | (#18201406)

chmod 600 crypt.key

Just make sure to store the key encrypted with a passphrase :)

Re:chmod 600 (0)

Anonymous Coward | more than 7 years ago | (#18202908)

The problem with your solution: if the computer goes offline, the files are easily readable by removing the hard drive, or by using a live cd. Really, the entire drive should be encrypted.

FIPS Levels (3, Insightful)

Jherek Carnelian (831679) | more than 7 years ago | (#18201410)

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]

Re:FIPS Levels (1, Funny)

Anonymous Coward | more than 7 years ago | (#18201622)

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

Yeah? My cryptography goes to 11.

Re:FIPS Levels (0)

Anonymous Coward | more than 7 years ago | (#18202694)

Mod points, mod points, wherefor art thou mod points...

No (4, Informative)

John.P.Jones (601028) | more than 7 years ago | (#18201666)

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.

Re:No (0)

Anonymous Coward | more than 7 years ago | (#18202834)

And supposedly, certified in a way that if incorporated into an application, requires the application to be separately FIPS 140-2 certified.

Eggs and baskets (4, Insightful)

El Cubano (631386) | more than 7 years ago | (#18201442)

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 (5, Informative)

Just Some Guy (3352) | more than 7 years ago | (#18201930)

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.

Re:Eggs and baskets (0)

Anonymous Coward | more than 7 years ago | (#18233828)

Yes, good points, but if my way is better than yours and yours is compromised, I am still secure. I believe that is why some run 'alternative' software like MacOSX or Opera. Not that it always helps...

Re:Eggs and baskets (0)

Anonymous Coward | more than 7 years ago | (#18201990)

You're right! Putting a copy of all your eggs into a dozen different baskets is the much better plan. Why spend all your time and energy developing a security plan for one important basket, when its so much more productive to develop a security plan for several equally important baskets?

Re:Eggs and baskets (1)

IkeTo (27776) | more than 7 years ago | (#18202832)

> Maybe it's just me, but I think that putting all your eggs in one basket is not smart.

I don't know whether it is just you, but I'm sure I'm not with you.

First, the eggs are "quantum encumbered", breaking one in a basket is equivalent to breaking the corresponding one in another basket. Most of the time, if you configure multiple ways store keys to access something sensitive (say, a server), the same access required in multiple ways, so you end up having the key (or keys of equivalent functionalities) in multiple places, breaking any of them allows attacker to access what you considered sensitive.

Second, the baskets are quantum encumbered as well, in such a way that if one breaks, the probability that the other will break as well is higher. This is because in an open-source world, code get shared.

Third, you have about the same amount of time to care the baskets no matter how many baskets you want to manage. No matter whether you have a single key ring application or 3, you only want to update your computer once per day, you only have those few hundred (say) of security experts capable of looking for security holes, etc.

So I'll instead take the mantra "keep all your eggs in the same basket, and look after it carefully" instead of "keep your eggs in many different baskets".

Aladdin eToken (1)

Vihai (668734) | more than 7 years ago | (#18201464)

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? (1, Insightful)

HomelessInLaJolla (1026842) | more than 7 years ago | (#18201484)

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.

Protected memory (0, Troll)

Gothmolly (148874) | more than 7 years ago | (#18201724)

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

Rollofle, rollofle, rollofle.

Sorry, now that I have that out of my system, consider if anything MS produces truly uses protected memory. Or maybe it does, but then you install some nefarious software, and that runs as system, and it hacks your buzzord-compliant encryption, and your game, as they say, is over.

Re:Protected memory (1)

Skreems (598317) | more than 7 years ago | (#18201966)

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.

Re:Protected memory (1)

Phillup (317168) | more than 7 years ago | (#18202572)

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.
How's that 'final arbiter' stuff work with virtualization?

Just wondering...

Trusted Platform Module (1)

tepples (727027) | more than 7 years ago | (#18203656)

How's that 'final arbiter' stuff work with virtualization?
The TPM distinguishes virtualization from running on bare hardware by logging boot time activity. If the hypervisor passes TPM calls through to the TPM hardware, then the TPM will show that two operating systems are loaded (the host and the client), and apps running on the emulated OS can detect this. If the hypervisor emulates a TPM, then Trusted Computing Group will sign the emulated TPM's public key with an "emulator" signature (not a "hardware" signature), and apps running on the emulated OS can detect this as well.

Re:Trusted Platform Module (1)

_damnit_ (1143) | more than 7 years ago | (#18204562)

Very nice. Wish I had mod points. What if you are using plain BIOS motherboard with no TPM? Good question. I suppose running on vmware or other vm would invalidate any certification based on running bare metal.

Re:Protected memory (3, Interesting)

Harik (4023) | more than 7 years ago | (#18202686)

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.

Re:Protected memory (1)

SirTalon42 (751509) | more than 7 years ago | (#18203662)

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.

Re:Protected memory (1)

Skreems (598317) | more than 7 years ago | (#18204046)

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.

Re:Protected memory (2, Funny)

Goaway (82658) | more than 7 years ago | (#18202194)

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!

Re:Protected memory (1)

Gothmolly (148874) | more than 7 years ago | (#18203090)

Yes, when there is no actual Microsoft vulnerability

Say that out loud a few times.

Re:Protected memory (1)

the_B0fh (208483) | more than 7 years ago | (#18213016)

Do people really not keep up with these kinds of shit? Go read Peter Gutmann's breakms paper, all 3 of them.

Re:Protected memory (1)

poopdeville (841677) | more than 7 years ago | (#18204486)

i am in ur memoriez, hacking all ur encryption.

Linux Kernel keyring; openCryptoki (5, Informative)

omnirealm (244599) | more than 7 years ago | (#18201742)

Current versions of the Linux kernel have a key retention [lkml.org] feature. For PKCS#11, there is openCryptoki [sourceforge.net] .

Re:Linux Kernel keyring; openCryptoki (1)

Wonko the Sane (25252) | more than 7 years ago | (#18201992)

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 [auckland.ac.nz] ?

Re:Linux Kernel keyring; openCryptoki (4, Interesting)

tlhIngan (30335) | more than 7 years ago | (#18203358)

Any idea if that mechanism addresses the DRAM "memory" effect described in this paper: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_ [auckland.ac.nz] 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.

Re:Linux Kernel keyring; openCryptoki (0)

Anonymous Coward | more than 7 years ago | (#18205184)

Same here with my notebook. Sometimes I can still see the last screen from graphics mode (i.e. the logout screen) when it is switched in to graphis again after a power cycle.

What about (0, Offtopic)

ET_Fleshy (829048) | more than 7 years ago | (#18202036)

truecrypt [truecrypt.org] ?

Windows encryption trustworthy? (1)

J'raxis (248192) | more than 7 years ago | (#18202428)

From "Vista encryption 'no threat' to computer forensics [theregister.co.uk] ":

We're seeing the same concerns with Vista as we saw with XP over the idea that built-in encryption features might frustrate law enforcement efforts. In practice XP has not proved to be a problem for computer forensics and we don't think Vista will be either," said Bill Thompson, director of professional development and training at Guidance Software.

Re:Windows encryption trustworthy? (1)

ClamIAm (926466) | more than 7 years ago | (#18202600)

Um, Windows's crypto features don't hurt forensics work mostly because nobody uses them. I'm not sure if you're aware of this, but security systems tend not to work when you don't turn them on.

However if every Windows user used these features maximally, these forensics people would probably be singing a different tune...

Re:Windows encryption trustworthy? (1)

J'raxis (248192) | more than 7 years ago | (#18205094)

I would hope so. In fact the next sentence in the article was Mr Thompson saying that "sometimes people use file wiping utilities or other tools but often they are not configured properly. People accept the default settings, which can leave fragments of data." So, yeah. Idiocy is its own rewar^W punishment. But the article also mentioned earlier that this BitLocker supports a second "recovery" key, so who knows how secure it is even if you use it right?

Re:Windows encryption trustworthy? (1)

ClamIAm (926466) | more than 7 years ago | (#18211528)

Well, about the "recovery key":

However, in corporate environments a BitLocker recovery key can be used to allow examination of target devices.

This sounds to me more like a key that IT keeps hidden away until an investigation (government or otherwise) needs to be done.

Even setting this aside, I think you're on the right track: the only people who really know how secure it is are the people who wrote it. And let's not count out exploits...

Re:Windows encryption trustworthy? (1)

J'raxis (248192) | more than 7 years ago | (#18235144)

Most likely, but I've heard enough about administrative backdoors in products to be suspicious. Of course, those are just secret passwords, not decryption keys, so it's not the same issue. But I'd be very suspicious of BitLocker, that in non-corporate environments, your copy of the OS might come conveniently pre-configured with a recovery key that only the OEM knows about.

Not sure what's out there for OSX. Their standard FileVault supports a recovery password so it goes in the same boat as BitLocker in my opinion.

Well... (1)

nacturation (646836) | more than 7 years ago | (#18202664)

It sounds like Linux needs a good dose of DRM to keep those keys secure.
 

Loopback filesystems? (0)

Anonymous Coward | more than 7 years ago | (#18202732)

How about storing private keys in a small encrypted loopback filesystem? With something like pam_mount the password for the filesystem can also act as the user password.

Re:Loopback filesystems? (2, Insightful)

ThePhilips (752041) | more than 7 years ago | (#18205170)

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.

Not necessarily provided... (1)

Kalzus (86795) | more than 7 years ago | (#18203506)

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

Smart Card (1)

Jeffrey Baker (6191) | more than 7 years ago | (#18203720)

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.

Re:Smart Card (2, Interesting)

mr_death (106532) | more than 7 years ago | (#18204038)

At the RSA conference three years ago, you could bring your smart card to many booths and they would extract the private key in less than 5 minutes. I have no reason to believe that the problem has become any harder.

True, a smart card (compared to a normal PC) sucks less, but it still sucks.

Re:Smart Card (1)

12dec0de (26853) | more than 7 years ago | (#18207008)

True, a smart card (compared to a normal PC) sucks less, but it still sucks.

Hmm... another comment that shows how little anybody here knows anything about security hard- and software.

There are so many different types of smartcards. And those with validated key protection schemes (CC, FIPS, etc.) you will not get at at all. But if you are only willing to pay for a memory card I would consider 5 Minutes rather long.

mfg lutz

Re:Smart Card (1)

mr_death (106532) | more than 7 years ago | (#18207878)

Hmm... another comment that shows how little anybody here knows anything about security hard- and software.

And, of course, you're omniscient, so you know everything.

And those with validated key protection schemes (CC, FIPS, etc.) you will not get at at all.

Bullshit. Tamper resistance on these devices is a joke. Data can be sniffed, either on board or between devices. Biometrics are spoofable. PINs are simple. Keys can be found.

Worshiping at the altar of Common Criteria and FIPS does little more than assure you didn't do something really stupid. Those standards are not sufficient for real security.

But, of course, you're free to keep deluding yourself.

Re:Smart Card (1)

corychristison (951993) | more than 7 years ago | (#18208480)

Smart Card
Oh neat! Is that one of those new fangled daemons for them new fangled Smart Car's I've been hearing so much about?

;-)

not possible (1)

mr_death (106532) | more than 7 years ago | (#18203976)

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.

I think we did this first... (2, Insightful)

SanityInAnarchy (655584) | more than 7 years ago | (#18204192)

... 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:I think we did this first... (3, Informative)

Anonymous Coward | more than 7 years ago | (#18205332)

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 (3, Informative)

Hannes Eriksson (39021) | more than 7 years ago | (#18205774)

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:

  • You have to have super-user privileges, CAP_SYS_PTRACE capabilities or be able to send signals to the process to "attach to". The first parts means you is or have the permission of the system administrator or compromised the system. The last part basically means that you can also poke around at will in "your own" (or all processes for the same user account you've hacked) processes.
  • It is possible to read and write all process memory and registers. Basically, this means that you can run, you can obfuscate, but you cannot hide your crypto keys. Not from yourself or a particularly Evil sysadm, that is.
  • Even if the traced process receives a signal from the tracing, it is already too late to do anything about it once it regains control over it's operation.

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!

Re:I think we did this first... (1)

jallen02 (124384) | more than 7 years ago | (#18205948)

The advantage is that it takes advantages of Windows authentication to do all of the encryption operations so it greatly reduces the overhead for the programmers dealing with the DPAPI. It really seems like an easy thing to dismiss, but then you have to consider how horribly most developers screw up crypto in their applications and the DPAPI makes a lot more sense.

Re:I think we did this first... (1)

rastos1 (601318) | more than 7 years ago | (#18207188)

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.
That's why man gdb says:

You can, instead, specify a process ID as a second argument, if you want to debug a running process:

gdb program 1234

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?
FAQ [gnupg.org] . There is no libgpg, and probably never will be.

Re:I think we did this first... (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18207764)

Aha. Then libssl, which seems to be used by everything but gpg.

It does seem I was entirely wrong about "attaching" to a running process. Fortunately for me, it doesn't actually affect me, as I don't use passphrases much. If you have physical access, or if you have my local user account, you've 0wned me already.

Re:I think we did this first... (0)

Anonymous Coward | more than 7 years ago | (#18207922)

OpenID is a web-based authentication method only. It relies on HTTP redirects.

Re:I think we did this first... MOD THIS DOWN (0)

Anonymous Coward | more than 7 years ago | (#18208070)

This is absolute rubbish. Why is it "3 insightful"?

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

I don't mind the poster being ignorant, but I do object to them getting modded up for it.

gdb -p

Re:I think we did this first... MOD THIS DOWN (1)

SanityInAnarchy (655584) | more than 7 years ago | (#18209820)

You're right, there needs to be a "-1 Wrong" mod for just this kind of stupidity.

I apologize.

Plan 9's Factotum (2, Interesting)

Darren Bane (21195) | more than 7 years ago | (#18205554)

Plan 9 [bell-labs.com] has such a central key repository. It's called Factotum, and the best description is the USENIX paper [usenix.org] . It has been ported to other UNIX-likes by the plan9port [swtch.com] project.

Re:Plan 9's Factotum (1)

Bob Uhl (30977) | more than 7 years ago | (#18209932)

Plan 9 did a lot of stuff well & smartly, generally out-Unixing Unix. Unfortunately, it came along too late--and was proprietary for too long--making its market impact pretty much nil. Which once again proves that if one wants to change the world, one really ought to free one's code.

Hardware Security Modules (1)

gzunk (242371) | more than 7 years ago | (#18205696)

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.

Encrypted keys in memory? You sure? (1)

the_B0fh (208483) | more than 7 years ago | (#18207542)

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.

Dont be fooled!!! (1)

Netino (1021745) | more than 7 years ago | (#18210936)

That Windows key is *completely* accessible when Windows is off. When you mount the Windows filesystem (NTFS) via Linux, for example, the entries are encripted, by you can crack them in minutes. So, this is only security by obscurity. Regards, Netino
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?